View Full Version : google paga per programmare open source
http://code.google.com/summerofcode.html
spero non sia già stata postata :)
in breve google paga 4,500$ per gli studenti che completano un progetto (open source) entro la fine dell'estate. la cifra non è affatto male :)
io ci sto facendo un pensierino anche se purtroppo il tempo non è molto, manca una settimana... se l'avessi scoperto prima mi sarei organizzato ma al momento non saprei cosa fare. ci sono dei progetti per i quali ho già competenze ma manca troppo poco cavolo!!
Un'ottima iniziativa. Alcuni progettini in effetti non sembrano difficili. Averlo saputo prima mi sarei organizato anche io anche perchè 4500€ in piu fanno sempre comodo. :D
ciao ;)
Facili fino ad un certo punto. I lavori devono essere accettati dai rispettivi release manager dei vari progetti.
mi sono letto il progetto del DIBEngine proposto da Wine: leggendolo mi sono reso conto di quanto faccia schifo Wine... veramente strano che certe volte vada più veloce di Windows, anzi non ci credo proprio.
VegetaSSJ5
07-06-2005, 17:42
mi sono letto il progetto del DIBEngine proposto da Wine: leggendolo mi sono reso conto di quanto faccia schifo Wine... veramente strano che certe volte vada più veloce di Windows, anzi non ci credo proprio.
premetto che non ho mai usato wine, cmq perchè dici questo? :confused:
Fenomeno85
07-06-2005, 17:48
io ho provato wine e dire che fa schifo è dir poco
~§~ Sempre E Solo Lei ~§~
RaouL_BennetH
07-06-2005, 18:06
io ho provato wine e dire che fa schifo è dir poco
~§~ Sempre E Solo Lei ~§~
Ma per te il discorso non vale :O
Tu hai provato un emulatore dentro un emulatore, manco fosse nu gruppo di matrioske :D
A parte scherzi, ricordo male o tu usi linux con vmware da windows?!?
P.S.: se ricordo male, la giuria è pregata di non tenere conto delle ultime dichiarazioni!! :)
Fenomeno85
07-06-2005, 18:11
Ma per te il discorso non vale :O
Tu hai provato un emulatore dentro un emulatore, manco fosse nu gruppo di matrioske :D
A parte scherzi, ricordo male o tu usi linux con vmware da windows?!?
P.S.: se ricordo male, la giuria è pregata di non tenere conto delle ultime dichiarazioni!! :)
no mai riprovato sotto l'emulazione ma che hai contro il potere di uccidere linux?? :D ... lo avevo provato sotto suse versione installata a parte
~§~ Sempre E Solo Lei ~§~
Fenomeno85
07-06-2005, 18:11
ma alla fine wine mica è morto e adesso c'è una versione a pagamento?? :D
~§~ Sempre E Solo Lei ~§~
RaouL_BennetH
07-06-2005, 18:20
no mai riprovato sotto l'emulazione ma che hai contro il potere di uccidere linux?? :D ... lo avevo provato sotto suse versione installata a parte
~§~ Sempre E Solo Lei ~§~
ah :D lol!
Comunque, fino ad ora non ho mai usato wine, non so...però qualche neurone per guadagnare sti eurini potremmo pure donarlo all'altare sacrificale della programmazione.
Io ho fatto una rubrica + un programmino in C che legge dei badge magnetici utilizzando mysql, può servire ?!? :D
io ho provato wine e dire che fa schifo è dir poco
~§~ Sempre E Solo Lei ~§~
non ne ho mai visto il sorgente, ma fa il suo lavoro in modo eccellente.
spesso bisogna metterci le mani e tirarci delle testate, ma fa davvero molto (tra l'altro non è assolutmentente un lavoro semplice).
poi certo, chi sa fare di meglio può sempre mettersi a riscriverlo ;)
cmq è vero, ci sono applicazioni (io usavo cs a suo tempo) che girano più veloci che su windows :eek:
tornando in 3d sono anche io daccordo che ci sono cose davvero molto facili (date un'occhiata a ubutnu ad esempio).
ovviamente dubito che passeranno tra le 200 proposte prese.
ciao
premetto che non ho mai usato wine, cmq perchè dici questo? :confused:
l'hai letta la descrizione del progetto? si arguisce chiaramente che le chiamate Win32 sono tradotte in chiamate Linux (lì ad es. parla di X); non so se user-mode o kernel-mode, ma non farebbe comunque molta differenza.
tecnicamente questa cosa è pessima: se già così Wine è più veloce di Windows (ci credo molto poco...) pensa a quanto potrebbe esserlo se traducesse le chiamate Win32 direttamente in chiamate ai drivers, al limite con l'intermediazione di processi di sistema per essere conformi al modello microkernel (che è il migliore); è così che avrebbe dovuto essere fatto, e non mi venite a dire che in Linux non si può perché a quel punto quello sterco di sistema operativo (:)) perderebbe definitivamente quel *pochissimo* della mia ammirazione che è faticosamente riuscito a guadagnarsi...
naturalmente non conosco Wine e quindi può darsi che effettivamente faccia quello che dico per interfacce che non riguardano la grafica, ma sicuramente per la grafica non lo fa.
infine aggiungo anche che facendo come ho detto si sarebbe ottenuto una specie di WOL (Wine Over Linux :p) dall'architettura molto migliore di Linux stesso (sapevo (potrei sbagliarmi) che Linux non è microkernel; in teoria il miglior modello per l'architettura di un SO è quello usato da Windows NT, ovvero l'ibrido tra microkernel e monolitico).
l'hai letta la descrizione del progetto? si arguisce chiaramente che le chiamate Win32 sono tradotte in chiamate Linux (lì ad es. parla di X); non so se user-mode o kernel-mode, ma non farebbe comunque molta differenza.
tecnicamente questa cosa è pessima: se già così Wine è più veloce di Windows (ci credo molto poco...) pensa a quanto potrebbe esserlo se traducesse le chiamate Win32 direttamente in chiamate ai drivers,
Nel senso che secondo te dovrebbe andare a parlare direttamente con i driver nvidia oppure peggio ancora agire sui registri della scehda video ? Secondo me la scelta che hanno fatto è senza dubbio la migliore. Se wine vede una chiamata a RtlMoveMemory la sostituisce semplicemente con memcpy, se vede del codice per disegnare come Arc e BitBlt è inutile parlare con i driver quando X puo farlo per te e magari sfruttare l'accellerazione grafica della scheda.
che Linux non è microkernel; in teoria il miglior modello per l'architettura di un SO è quello usato da Windows NT, ovvero l'ibrido tra microkernel e monolitico).
Che in teoria la microkernel sia la migliore è risaputo. Ma scriverne uno efficente quanto uno monolitico è tutta un'altra storia.
ciao ;)
Nel senso che secondo te dovrebbe andare a parlare direttamente con i driver nvidia oppure peggio ancora agire sui registri della scehda video ? Secondo me la scelta che hanno fatto è senza dubbio la migliore. Se wine vede una chiamata a RtlMoveMemory la sostituisce semplicemente con memcpy, se vede del codice per disegnare come Arc e BitBlt è inutile parlare con i driver quando X puo farlo per te e magari sfruttare l'accellerazione grafica della scheda.chi ha parlato di fare direttamente IO sulle periferiche? è chiaro che non puoi: anche volendo nel 90% dei casi non hai le specifiche, quindi...
io parlavo di comunicare coi drivers, si: e allora? che problema c'è? non sembra anche a te la soluzione più veloce? anziché passare per X, non conviene comandare direttamente i drivers? tu dirai che allora bisogna praticamente realizzare un nuovo kernel basato su Unix ma con interfaccia Windows (quello che intendevo quando parlavo scherzosamente di "WOL" :p), embe'? lavorassero gli scansafatiche!! :p :p :p :D :sofico:
ovviamente scherzo, non obbligo nessuno a fare una cosa che non gli è richiesta, ma se non sono in grado di realizzare quello che piace a me, io non installerò quello che invece hanno realizzato... se poi non piace a me però piace a te è un'altra storia, ma ti avviso che numerosi "linuxisti" hanno definito malamente Wine... ;)
Che in teoria la microkernel sia la migliore è risaputo. Ma scriverne uno efficente quanto uno monolitico è tutta un'altra storia. la questione è diversa: dove hai bisogno di efficienza (ad esempio in grafica) usi il modello monolitico, dove invece non ne hai bisogno (ad esempio la sicurezza, la sincronizzazione, ecc.) usi il microkernel; come fa Windows NT insomma :)
chi ha parlato di fare direttamente IO sulle periferiche? è chiaro che non puoi: anche volendo nel 90% dei casi non hai le specifiche, quindi...
io parlavo di comunicare coi drivers, si: e allora? che problema c'è? non sembra anche a te la soluzione più veloce? anziché passare per X, non conviene comandare direttamente i drivers?
Devi scrivere un sacco di codice in piu e debuggarlo. Alla fine non è detto che quello che hai scritto avra prestazioni migliori. Quindi secondo me il gioco non vale la candela.
non sono in grado di realizzare quello che piace a me, io non installerò quello che invece hanno realizzato... se poi non piace a me però piace a te è un'altra storia, ma ti avviso che numerosi "linuxisti" hanno definito malamente Wine... ;)
Sono uno di quelli. Considero wine una perdita di tempo comunque. Se devo usare una app di Windows faccio 100 volte prima ad avviare Windows che cercare di configurare wine per farlo andare malaccio.
la questione è diversa: dove hai bisogno di efficienza (ad esempio in grafica) usi il modello monolitico, dove invece non ne hai bisogno (ad esempio la sicurezza, la sincronizzazione, ecc.) usi il microkernel; come fa Windows NT insomma :)
Sicurezza in windows ?? :Prrr:
ciao ;)
Tecnicamente ha ragione Vicius. Per diversi motivi su cui bisogna fare delle considerazioni. I driver in realta' sono un pezzo di sistema operativo. Sono soltanto un pezzo di codice che utilizza le chiamate SO che un produttore realizza autonomamente per consentire al proprio dispositivo di comunicare con il sistema operativo senza dover "sputtanare" le proprie caratteristiche hardware. Le API del sistema operativo sono appunto un mezzo che il sistema offre per estendere le proprie funzionalita' (leggasi supporto hardware) mediante la scrittura di driver (moduli di kernel, cioe' di sistema operativo). Un driver, quindi, non fa altro che "convertire" le chiamate che implementano determinate funzionalita' in chiamate primitive del sistema operativo, fornendo a sua volta, in certi casi, delle API a piu' alto livello.
L'approccio che usa Wine, quindi, e' il piu' naturale. Si sbaglia infatti a pensare che Wine sia un emulatore. Proprio il nome, Wine, e' un acronimo ricorsivo che significa "Wine Is Not an Emulator", ma e' proprio un implementazione delle API win32 per sistemi Unix. Proprio per questa natura, convertire le chiamate di piu' alto livello in chiamate native di SO e' l'approccio migliore, proprio perche' le API win32 non sono altro che un'implementazione a piu alto livello delle chiamate di sistema. E' un approccio a strati, come si usa in tutti i sistemi operativi con le loro API. Pertanto e' l'approccio migliore.
non so perché ma ho l'impressione che sta cosa sia venuta fuori un po' all'ultimo momento per favorire chi l'ha scoperta in anticipo e ha avuto il tempo di prepararsi...
cmq ci sono progetti che sono fattibili, solo che bisognava saperlo un po' prima maledizione...
Devi scrivere un sacco di codice in piu e debuggarlo. Alla fine non è detto che quello che hai scritto avra prestazioni migliori. Quindi secondo me il gioco non vale la candela. è detto eccome:
caso 1) tu hai un programma che chiama una funzione API in User Mode, la funzione chiamata è implementata da Wine, che la converte in una chiamata User Mode alle API di Linux; la chiamata si propaga nei meandri del kernel di Linux fino ad essere convertita in Kernel Mode ed arrivare ai drivers.
case 2) l'applicazione chiama l'API Win32, questa si propaga nei meandri di un ipotetico sistema WOL fino ad essere convertita in Kernel Mode e ad essere tradotta (sempre da questo "WOL") in una chiamata ai drivers.
quale dei due casi è più efficiente, considerando che nel primo devi passare da un'architettura ad un'altra che credo sia completamente diversa, e che quindi passi per due implementazioni diverse dello strato User Mode?
Sono uno di quelli. Considero wine una perdita di tempo comunque. Se devo usare una app di Windows faccio 100 volte prima ad avviare Windows che cercare di configurare wine per farlo andare malaccio. se Wine fosse fatto come dico io lo apprezzeresti di più, anche perché probabilmente sarebbe realmente più veloce del Windows originale.
Sicurezza in windows ?? :Prrr: cioè, tu conosci il modo di bypassare il sistema di sicurezza di Windows NT?!? ti venero!!! :ave:
e saresti anche così gentile da postarmi un codice esemplificativo che faccia ad esempio che ne so, che riesca ad aprire un handle valido di un altro processo al quale normalmente non può accedere? :)
o sennò qualcos'altro insomma, vedi un po' tu. :)
Tecnicamente ha ragione Vicius. Per diversi motivi su cui bisogna fare delle considerazioni. I driver in realta' sono un pezzo di sistema operativo. Sono soltanto un pezzo di codice che utilizza le chiamate SO che un produttore realizza autonomamente per consentire al proprio dispositivo di comunicare con il sistema operativo senza dover "sputtanare" le proprie caratteristiche hardware. Le API del sistema operativo sono appunto un mezzo che il sistema offre per estendere le proprie funzionalita' (leggasi supporto hardware) mediante la scrittura di driver (moduli di kernel, cioe' di sistema operativo). Un driver, quindi, non fa altro che "convertire" le chiamate che implementano determinate funzionalita' in chiamate primitive del sistema operativo, fornendo a sua volta, in certi casi, delle API a piu' alto livello.
L'approccio che usa Wine, quindi, e' il piu' naturale. Si sbaglia infatti a pensare che Wine sia un emulatore. Proprio il nome, Wine, e' un acronimo ricorsivo che significa "Wine Is Not an Emulator", ma e' proprio un implementazione delle API win32 per sistemi Unix. Proprio per questa natura, convertire le chiamate di piu' alto livello in chiamate native di SO e' l'approccio migliore, proprio perche' le API win32 non sono altro che un'implementazione a piu alto livello delle chiamate di sistema. E' un approccio a strati, come si usa in tutti i sistemi operativi con le loro API. Pertanto e' l'approccio migliore.
ok, ok, senti: le mie spalle con questo post hanno quasi toccato terra, quindi dimmi subito una cosa (senza nessuna offesa): vuoi veramente che ti rispondo, oppure ce ne sbattiamo tutti e due e continuiamo a vivere felici e relativamente contenti? :)
ok, ok, senti: le mie spalle con questo post hanno quasi toccato terra, quindi dimmi subito una cosa (senza nessuna offesa): vuoi veramente che ti rispondo, oppure ce ne sbattiamo tutti e due e continuiamo a vivere felici e relativamente contenti? :)
Visto la risposta chiaramente orientata verso una possibile flame, a questo punto ti dico che pr terra a me adesso ci toccano le p@lle. Quindi magari visto la tua superiorita' tecnica, le considerazioni non metterle qui. Che tanto noi non siamo sviluppatori Wine. Magari iscriviti sulla loro mailing list e digli che hai un'implementazione migliore. Fatti inoltre una domanda: come mai ci hai pensato tu e solo tu e non tutte le centinaia di sviluppatori che ci sono passati sotto (a Wine). Una volta che ti sei risposto "perche' sono un genio e sono in grado di implementarlo" proponiti come loro leader. Quando la tua idea sara' stata riconosciuta fattibile dai tuoi seguaci sulla mailing list, torna qui'. Prima di cio', non mi interessa niente. Io sono felice comunque ;)
DanieleC88
08-06-2005, 15:58
Visto la risposta chiaramente orientata verso una possibile flame, [et cetera] Io sono felice comunque ;)
Concordo con te, mjordan. Torniamo in argomento.
Alberto, ma ce l'hai proprio a morte con WINE! :D Te l'avrò detto mille volte, se non ti piace, non usarlo!
P.S.: ma i progetti devono essere *completati* e presentati entro il 14? E chi ha 16 anni può partecipare? (Temo di no, ma...)
è detto eccome:
caso 1) tu hai un programma che chiama una funzione API in User Mode, la funzione chiamata è implementata da Wine, che la converte in una chiamata User Mode alle API di Linux; la chiamata si propaga nei meandri del kernel di Linux fino ad essere convertita in Kernel Mode ed arrivare ai drivers.
case 2) l'applicazione chiama l'API Win32, questa si propaga nei meandri di un ipotetico sistema WOL fino ad essere convertita in Kernel Mode e ad essere tradotta (sempre da questo "WOL") in una chiamata ai drivers.
quale dei due casi è più efficiente, considerando che nel primo devi passare da un'architettura ad un'altra che credo sia completamente diversa, e che quindi passi per due implementazioni diverse dello strato User Mode?
Non ho capito bene come è strutturato questo WOL. Ma alla fine che cosa si risparmia forse una CALL e qualche CMP ? :confused:
cioè, tu conosci il modo di bypassare il sistema di sicurezza di Windows NT?!? ti venero!!! :ave:
e saresti anche così gentile da postarmi un codice esemplificativo che faccia ad esempio che ne so, che riesca ad aprire un handle valido di un altro processo al quale normalmente non può accedere? :)
o sennò qualcos'altro insomma, vedi un po' tu. :)
La faccina con la lingua di fuori non si è vista vero ?
Io di certo no. Faccio altro nel tempo libero. In ogni caso i bug di sicurezza sono all'ordine del giorno in Windows come in tutti gli altri sistemi. Altrimenti non si spiegherebbe come mai tanta gente si sforzi di creare anti-virus-spyware-malware-trojan, firewall e compagnia bella.
ciao ;)
Non ho capito bene come è strutturato questo WOL. Ma alla fine che cosa si risparmia forse una CALL e qualche CMP ? :confused: a parte che anche solo quelle avrebbero il loro effetto positivo, cmq secondo me si risparmia molto di più. perché poi secondo te il kernel di Linux sarebbe composto sostanzialmente solo da qualche CALL e CMP?
La faccina con la lingua di fuori non si è vista vero ? se non la faccio non si vede :)
(1, 2, 3... prova... :p czzz... <prova> :p... :p :p ok)
Io di certo no. Faccio altro nel tempo libero. In ogni caso i bug di sicurezza sono all'ordine del giorno in Windows come in tutti gli altri sistemi. Altrimenti non si spiegherebbe come mai tanta gente si sforzi di creare anti-virus-spyware-malware-trojan, firewall e compagnia bella. se mi dici che su Linux non esistono antivirus mi metto a fare una di quelle risate che tipo inizi a ridere e poi continui a ridere solo perché non riesci più a smettere... :D ma non perché io so che non è vero, io non lo so se su Linux ci siano programmi di sicurezza (penso di si) e quanti ce ne siano :D
in Windows l'unico problema è che gli utenti normali fanno sempre account Administrator: se facessero account limitati, riservassero l'Administrator solo per la manutenzione del sistema, e accedessero a Internet solo con gli account limitati, ci sarebbero molti meno problemi.
cmq questo sarebbe un OT dell'OT, quindi sai quanto gliene importa agli altri in questo 3d :p
(ecco, ora l'ho fatta la faccina con la lingua)
Concordo con te, mjordan. Torniamo in argomento.
Alberto, ma ce l'hai proprio a morte con WINE! :D Te l'avrò detto mille volte, se non ti piace, non usarlo! e chi lo usa :D manco i linuxisti a momenti!! :D
Visto la risposta chiaramente orientata verso una possibile flame, a questo punto ti dico che pr terra a me adesso ci toccano le p@lle. tu te la canti e tu te la suoni: io finora non avevo intenzioni flammose... solo giustificata pigrizia di scrivere una risposta che oltre che lunga sarebbe stata OT e probabilmente non ti avrebbe nemmeno convinto.
Quindi magari visto la tua superiorita' tecnica, poi il flamer sono io, eh? o forse era un complimento sincero? non so perché ma ci credo poco...
le considerazioni non metterle qui. cosa vorresti invece tu su un forum di discussione, e precisamente nella sezione di programmazione?
Che tanto noi non siamo sviluppatori Wine. Magari iscriviti sulla loro mailing list e digli che hai un'implementazione migliore. non mi va, ho altri progetti per il mio futuro.
Fatti inoltre una domanda: come mai ci hai pensato tu e solo tu e non tutte le centinaia di sviluppatori che ci sono passati sotto (a Wine). che ci vuoi fare, i programmi di m***a esistono: pensa a quanto ti fa schifo Windows eppure a programmarlo saranno pure più di Wine...
Una volta che ti sei risposto "perche' sono un genio e sono in grado di implementarlo" proponiti come loro leader. non fa assolutamente per me (senza contare che Wine per me andrebbe praticamente rifatto, sai quanta voglia ne ho? :banned: )
Quando la tua idea sara' stata riconosciuta fattibile dai tuoi seguaci sulla mailing list, torna qui'. Prima di cio', non mi interessa niente. padrone; visto che non ti va di sentire utenti che in un forum esprimono la loro su certi argomenti anche senza esserne i più grandi esperti del mondo quella è la porta.
Io sono felice comunque ;) io ho quasi ricominciato ad esserlo; se non vedo nessun altro tuo post sull'argomento posso dire di esserlo di nuovo!
PS: con questo post l'OT è raggiunto, percui se vuoi continuare a rispondermi io sono qui, ma è meglio sia per te che per me spostarci da qualche altra parte, vedi tu; qui su HWU cmq non ti rispondo +, onde evitare un clamoroso :banned:
a parte che anche solo quelle avrebbero il loro effetto positivo, cmq secondo me si risparmia molto di più. perché poi secondo te il kernel di Linux sarebbe composto sostanzialmente solo da qualche CALL e CMP?
Se non capito male quindi Vorresti completamente scavalcare il kernel di linux ? :eek:
Ma non ti sembra assurdo ?
se mi dici che su Linux non esistono antivirus mi metto a fare una di quelle risate che tipo inizi a ridere e poi continui a ridere solo perché non riesci più a smettere... :D ma non perché io so che non è vero, io non lo so se su Linux ci siano programmi di sicurezza (penso di si) e quanti ce ne siano :D
in Windows l'unico problema è che gli utenti normali fanno sempre account Administrator: se facessero account limitati, riservassero l'Administrator solo per la manutenzione del sistema, e accedessero a Internet solo con gli account limitati, ci sarebbero molti meno problemi.
cmq questo sarebbe un OT dell'OT, quindi sai quanto gliene importa agli altri in questo 3d :p
(ecco, ora l'ho fatta la faccina con la lingua)
Pensavo si fosse capito che con quel "... in Windows come in tutti gli altri sistemi ..." che anche Linux e gli altri hanno bug di sicurezza. Non dirmi che cerchi di cambiare discorso :p
Comunque OT per OT. Certo che esistono antivirus. F-Secure, Avast, Sophos, H+BEDV e Clamav giusto per fare un piccolo elenco dei primi che mi vengono in mente. Il problema è che ad un utente desktop non servono a niente. Si tratta di prodotti da abbinare ad un server mail per filtrare virus indesiderati diretti a client Windows.
ciao ;)
tu te la canti e tu te la suoni: io finora non avevo intenzioni flammose... solo giustificata pigrizia di scrivere una risposta che oltre che lunga sarebbe stata OT e probabilmente non ti avrebbe nemmeno convinto.
Rileggi il tono che usi nei tuoi post, poi dimmi se la sensazione che ho avuto io era errata. Temo di no.
poi il flamer sono io, eh? o forse era un complimento sincero? non so perché ma ci credo poco...
Pura ironia. Se la tua era reale competenza tecnica stavi scrivendo codice al posto di scrivere qui. Per il progetto Wine.
cosa vorresti invece tu su un forum di discussione, e precisamente nella sezione di programmazione?
Discussioni in tema con il thread in cui si partecipa. L'OT da quello che vedo non l'ho cominciato io.
non mi va, ho altri progetti per il mio futuro.
Capisco. Quindi rifiuteresti un probabile ingaggio da Cedega... Wow... Questa e' reale competenza tecnica. Sembri Linus Torvalds che rifiuta il lavoro da Apple. :rolleyes:
che ci vuoi fare, i programmi di m***a esistono: pensa a quanto ti fa schifo Windows eppure a programmarlo saranno pure più di Wine...
Mai pensato che Windows fa schifo. Ho sempre creduto che copra bene il segmento che vuole coprire. Giochi, Entertainment, altro.
non fa assolutamente per me (senza contare che Wine per me andrebbe praticamente rifatto, sai quanta voglia ne ho? :banned: )
Wow... Fek, scusa... Mi senti??? Assumete costui alla Lionhead... :rotfl:
Non e' che avete un posticino alla Microsoft? Abbiamo trovato uno che stravolge l'architettura di un programma da un milione di righe di codice sorgente in 5 minuti.
padrone; visto che non ti va di sentire utenti che in un forum esprimono la loro su certi argomenti anche senza esserne i più grandi esperti del mondo quella è la porta.
No, io le opinioni le ascolto e di tutti. Anche le tue. Visto che sono qui.
Finiamola altrimenti Cionci si arrabbia e ci banna. Torniamo in tema, please.
Non penso che qui' ci sia molta gente interessata all'architettura di WINE...
State buoni tutti e due... su su su, siamo fra amici qui.
No, io le opinioni le ascolto e di tutti. Anche le tue. Visto che sono qui.
Finiamola altrimenti Cionci si arrabbia e ci banna. Torniamo in tema, please.
Non penso che qui' ci sia molta gente interessata all'architettura di WINE... comunque ti ho già detto che qui non ti risponderò + in merito a questa questione; stasera dopo cena se ho voglia ti rispondo in pvt.
PS: secondo te dove dovrebbero stare gli italiani interessati all'architettura di Wine se non nella sezione di Programmazione del forum di discussione del sito italiano sulla tecnologia?
:ciapet: dopo quella specie di strana ambiguità tra bot e ed essere umano di utente che ci è appena arrivato avevamo proprio bisogno di un troll nel forum.
Se non capito male quindi Vorresti completamente scavalcare il kernel di linux ? :eek:
Ma non ti sembra assurdo ? òoh, vedo che finalmente mi hai capito ;)
non è affatto assurdo, imho in teoria sarebbe la soluzione migliore, che c'è che non va? ;)
senza contare che imho solo così Wine può veramente definirsi un non-emulatore, non trovi? :)
finché si limita a tradurre le chiamate Win32 in chiamate Unix, in un modo o nell'altro sempre emulatore è (emula chiamate Unix).
Pensavo si fosse capito che con quel "... in Windows come in tutti gli altri sistemi ..." che anche Linux e gli altri hanno bug di sicurezza. Non dirmi che cerchi di cambiare discorso :p e vabbè scusa, allora stai dicendo che la sicurezza non esiste negli altri sistemi operativi come non esiste in Windows? :D
Comunque OT per OT. Certo che esistono antivirus. F-Secure, Avast, Sophos, H+BEDV e Clamav giusto per fare un piccolo elenco dei primi che mi vengono in mente. Il problema è che ad un utente desktop non servono a niente. Si tratta di prodotti da abbinare ad un server mail per filtrare virus indesiderati diretti a client Windows. be', Linux si sa, non è fatto per i desktop :p
comunque ti ho già detto che qui non ti risponderò + in merito a questa questione; stasera dopo cena se ho voglia ti rispondo in pvt.
PS: secondo te dove dovrebbero stare gli italiani interessati all'architettura di Wine se non nella sezione di Programmazione del forum di discussione del sito italiano sulla tecnologia?
No guarda te le puoi pure risparmiare le risposte. :sofico:
Gli italiani interessati a un progetto stanno sulle mailing list del progetto e parlano e collaborano in inglese come tutti quanti. O per lo meno aprono thread attinenti del tipo "Parliamo di WINE. Ho scoperto un'architettura alternativa".
dopo quella specie di strana ambiguità tra bot e ed essere umano di utente che ci è appena arrivato avevamo proprio bisogno di un troll nel forum.
Troll, bot, essere ambiguo. Ti riferisci a me o a Fek? :mbe:
No guarda te le puoi pure risparmiare le risposte. :sofico: perché non ti risparmi tu le tue? contengono solo un mare di OPS questo avrei dovuto dirglielo in pvt!! :D vabbè non resistevo ^_^'
Troll, bot, essere ambiguo. Ti riferisci a me o a Fek? :mbe: spiegazione a prova di mjordan:
bot & essere ambiguo -> fabriziolivorno
troll -> mjordan
è più chiaro? :)
scusate se perpetro l'OT ma la storia dell'architettura di Wine mi ha preso :) imho la soluzione corretta (per definirsi un non emulatore) è quella di 71104 in quanto Wine sarebbe in grado di chiamare le funzioni dei driver direttamente senza appoggiarsi al kernel.
la struttura si muterebbe quindi in
KERNEL LINUX --- WINE + APPLICATIVO Win32 (KERNEL e WINE allo stesso livello)
| |
| |
--------------------------------
|
|
Driver
|
|
Hardware
possiamo dire che KERNEL e WINE (ora sarebbe corretto chiamarlo WoL) sarebbero paritetici
il che si si riuscisse (parlo a condizionale, perchè sarebbe complesso) avrebbe un efficacia elevatissima perchè wine si trasformerebbe da emulatore (passando per lo strato del kernel, a quello dei driver ed infine al hw) a interprete arrivando tramite il driver al hw
ps il driver è uno strato di software di basso livello che c'è tra SO e HW e non sopra il SO tra SO e applicativi :)
o meglio la situazione sarebbe così:
http://img89.echo.cx/img89/9761/wine1bp.png
questo è quello che "Rosetta" farà con gli applicativi PPC da tradurre in x86 per i nuovi sistemi mac ;)
:ot: a parte ora sono soddisfatto...anche se ad aver saputo prima del concorso si poteva fare qualche cosetta ;)
scusate se perpetro l'OT ma la storia dell'architettura di Wine mi ha preso :) imho la soluzione corretta (per definirsi un non emulatore) è quella di 71104 in quanto Wine sarebbe in grado di chiamare le funzioni dei driver direttamente senza appoggiarsi al kernel.[...] be', che dire: :mano:
ps il driver è uno strato di software di basso livello che c'è tra SO e HW e non sopra il SO tra SO e applicativi :) vedo che hai aggiunto anche una nota comprensiva per persone limitate :) ma è meglio non fare nomi, altrimenti *mjordan* perde di colpo quella sua fastidiosa giocosità che lo caratterizza in modo così particolare e che lo rende immediatamente riconoscibile in mezzo alle persone normali :)
(mj., brutta fastidiosa donnina testa di :ncomment: :ncomment: AHEM!!! :D :D :D ancora una volta ho dimenticato di spostarmi in pvt :asd: )
o meglio la situazione sarebbe così:
questo è quello che "Rosetta" farà con gli applicativi PPC da tradurre in x86 per i nuovi sistemi mac ;)
:ot: a parte ora sono soddisfatto...anche se ad aver saputo prima del concorso si poteva fare qualche cosetta ;)
Il problema è che un SO non è fatto cosi. per quanto micro-kernel sia. I driver si basano sempre su dei servizi del kernel e non il contrario.
Per quanto riguarda rosetta se non sbaglio è un traduttore just in time che ha ancora alcune limitazioni riguardo a quello che puo tradurre.
ciao ;)
Il problema è che un SO non è fatto cosi. per quanto micro-kernel sia. I driver si basano sempre su dei servizi del kernel e non il contrario. possono continuare a farlo; l'importante è che il kernel originale non si interponga tra WINE (a sto punto chiamiamolo WoL :p) e i drivers.
volendo completare lo schema di sirus:
WINE + app. Win32
^
|
V
device drivers <----> kernel originale (driver support routines)
^
|
V
hardware
possono continuare a farlo; l'importante è che il kernel originale non si interponga tra WINE (a sto punto chiamiamolo WoL :p) e i drivers.
volendo completare lo schema di sirus:
WINE + app. Win32
^
|
V
device drivers <----> kernel originale (driver support routines)
^
|
V
hardware
La trovo una pessima idea. Permettere l'accesso direttamente ai driver ad applicazioni in user-space sarebbe una falla di sicurezza colossale. L'unico modo che un programma deve avere a disposizione per lavorare con le periferiche è tramite le system call del sistema operativo altrimenti si perdono tutti i vantaggi dell'astrazione che fornisce.
Nello schema qui sopra wine dovrebbe conoscere ogni singolo dettaglio di tutti i driver possibili ed immaginabili con cui dovrebbe parlare. Il codice da scrivere aumenterebbe a dismisura e per cosa un incremento del 1% o 2% ?
ciao ;)
La trovo una pessima idea. Permettere l'accesso direttamente ai driver ad applicazioni in user-space sarebbe una falla di sicurezza colossale. L'unico modo che un programma deve avere a disposizione per lavorare con le periferiche è tramite le system call del sistema operativo altrimenti si perdono tutti i vantaggi dell'astrazione che fornisce. e infatti chi ha parlato di User Space (supponendo che significhi User Mode parlando in Windowsiano)? hai mai un visto un kernel che funziona solo in User Mode??? è chiaro che lo strato "WINE" deve avere una parte User Mode e una parte Kernel Mode.
Nello schema qui sopra wine dovrebbe conoscere ogni singolo dettaglio di tutti i driver possibili ed immaginabili con cui dovrebbe parlare. Il codice da scrivere aumenterebbe a dismisura e per cosa un incremento del 1% o 2% ? che intendi per "conoscere ogni singolo dettaglio" dei drivers, di che dettagli parli? dell'interfaccia che questi offrono normalmente al sistema operativo? ovvio che deve conoscerla, il kernel di Linux la conosce. Comunque esageri nelle proporzioni: il codice da scrivere aumenta, certo, (vorrei ben vedere, stai riscrivendo un kernel), ma non così tanto da non farne valere la pena (è un giudizio empirico naturalmente, ma lo considero ben valido) e ti ripeto che l'incremento di prestazioni sarebbe notevole: sicuramente il risultato sarebbe più veloce dell'originale (Windows), e già solo per questo ne varrebbe la pena; poi mettici anche che l'attuale WINE in molti casi non è più veloce di Windows (e comunque ci credo poco che in certe situazioni lo è, come dicono: secondo me è più lento e basta).
e infatti chi ha parlato di User Space (supponendo che significhi User Mode parlando in Windowsiano)? hai mai un visto un kernel che funziona solo in User Mode??? è chiaro che lo strato "WINE" deve avere una parte User Mode e una parte Kernel Mode.
Non sapevo esistesse una versione "windowsiana" :)
Per processi in kernel space intendo tutti quelli interni al kernel eseguiti in supervisor mode dalla cpu e che quindi possono fare quello che gli pare. Quando parlo di processi in user space invece mi riferisco a tutti quei processi che vengono eseguiti con permessi ridotti nella loro angolino. Usano le syscall per parlare con il kernel e vengono uccisi appena tentano di sgarrare.
che intendi per "conoscere ogni singolo dettaglio" dei drivers, di che dettagli parli? dell'interfaccia che questi offrono normalmente al sistema operativo? ovvio che deve conoscerla, il kernel di Linux la conosce.
Interfaccie di driver come quello nvidia o ati sono molto complesse e difficili. L'interfaccia e le funzioni da chiamare su una S3 per disegnare un rettangolo grigio potrebbero essere differenti da quelle usate su una Voodoo 4 o una nvidia. Se poi il driver è di tipo closed source la cosa è praticamente certa.
sicuramente il risultato sarebbe più veloce dell'originale (Windows), e già solo per questo ne varrebbe la pena; poi mettici anche che l'attuale WINE in molti casi non è più veloce di Windows (e comunque ci credo poco che in certe situazioni lo è, come dicono: secondo me è più lento e basta).
Come fai a dire che sarebbe piu veloce dell'originale ? Alla microsoft non mi sembrano programmatori dilettanti. anzi.
ciao ;)
Non sapevo esistesse una versione "windowsiana" :)
Per processi in kernel space intendo tutti quelli interni al kernel eseguiti in supervisor mode dalla cpu e che quindi possono fare quello che gli pare. Quando parlo di processi in user space invece mi riferisco a tutti quei processi che vengono eseguiti con permessi ridotti nella loro angolino. Usano le syscall per parlare con il kernel e vengono uccisi appena tentano di sgarrare. allora si, è praticamente la stessa cosa: Kernel Mode è esattamente l'equivalente di ring0 negli Intel, mentre User Mode sarebbe ring3; il concetto in Linux da quanto capisco è simile. cmq è naturale che esistano User Mode e Kernel Mode anche in Windows: qualsiasi sistema operativo moderno che funzioni in modalità protetta ha qualcosa di simile.
Interfaccie di driver come quello nvidia o ati sono molto complesse e difficili. L'interfaccia e le funzioni da chiamare su una S3 per disegnare un rettangolo grigio potrebbero essere differenti da quelle usate su una Voodoo 4 o una nvidia. Se poi il driver è di tipo closed source la cosa è praticamente certa. MA CHE DICIII!!! naaa, non ci credo manco per niente, in Windows non è assolutamente così!!! se così fosse secondo te come dovrebbe fare un programmatore del kernel di Linux a usare sti drivers tutti completamente diversi tra loro?!? soprattutto quando poi in futuro potrebbero cambiare ulteriormente...
scusa, tu sai cos'è il DDK?
Come fai a dire che sarebbe piu veloce dell'originale ? Alla microsoft non mi sembrano programmatori dilettanti. anzi. io certe persone proprio non capisco da che parte stanno :D
cmq il problema non è l'abilità dei programmatori che lavorano da quelle parti, anzi la ci stanno fior di cervelli tra i migliori del mondo (Matt Pietrek ad es.: lo ammiro molto, ho letto 1 sacco di sue cose su MSDN Magazine :)), il problema sono sempre i soldi, come al solito: Microsoft è un muflone commerciale, grosso e lento, e i fiori di cervelli ahimè devono fare i comodacci suoi :-\
Windows LH come tutti sanno sarà di un peso che noi oggi consideriamo inaccettabile, e quando uscirà per molti utenti comuni sarà accettabile solo grazie alle tecnologie che ci saranno (1 giga di RAM sarà all'ordine del giorno, questo è vero, ma ti pare giusto che un SO debba richiedere 1 giga di RAM come requisito consigliato e 512 minimi?).
be', che dire: :mano:
vedo che hai aggiunto anche una nota comprensiva per persone limitate :) ma è meglio non fare nomi, altrimenti *mjordan* perde di colpo quella sua fastidiosa giocosità che lo caratterizza in modo così particolare e che lo rende immediatamente riconoscibile in mezzo alle persone normali :)
(mj., brutta fastidiosa donnina testa di :ncomment: :ncomment: AHEM!!! :D :D :D ancora una volta ho dimenticato di spostarmi in pvt :asd: )
Ascolta, la finisci subito o ti segnalo ad un moderatore? Vedi di usare un tono rispettoso.
Implementare la WIN32 API senza passare per il Kernel... :rolleyes:
Analisi computazionale fatta a mente :doh:
Chiamare i driver senza passare per il sistema operativo neanche i driver funzionassero per mano dello Spirito Santo :doh:
Compiti da sistema operativo dentro le API :doh:
Pare di stare a vedere un film di Spielberg.
Ascolta, la finisci subito o ti segnalo ad un moderatore? Vedi di usare un tono rispettoso.
Scusami eh.. ma sto ridendo come un cretino.. :D :D
Il problema è che un SO non è fatto cosi. per quanto micro-kernel sia. I driver si basano sempre su dei servizi del kernel e non il contrario.
Per quanto riguarda rosetta se non sbaglio è un traduttore just in time che ha ancora alcune limitazioni riguardo a quello che puo tradurre.
ciao ;)
se fosse proprio come dici tu, quando il SO deve visualizzare una modifica del desktop che fa?!
invece i driver si posizionano ad uno strato logicamente inferiore (poi sono dei programmi e per essere un esecuzione necessitano del SO ;) ) inquanto quando c'è una pressione sul pulsante start (per esempio) windows reagisce dicendo al driver video di istruire la vga in modo da far comparire il menù...
quindi vedi che è il SO che chiama le primitive dei driver ;)
se fosse proprio come dici tu, quando il SO deve visualizzare una modifica del desktop che fa?!
invece i driver si posizionano ad uno strato logicamente inferiore (poi sono dei programmi e per essere un esecuzione necessitano del SO ;) ) inquanto quando c'è una pressione sul pulsante start (per esempio) windows reagisce dicendo al driver video di istruire la vga in modo da far comparire il menù...
quindi vedi che è il SO che chiama le primitive dei driver ;)
Qundo clicchi il bottone Start, si emette un evento. Questo evento, gestito dall'API win32, viene gestito dall'API. L'API gestisce tale evento ed emette un segnale che invia al sistema operativo. Il sistema operativo raccoglie tale segnale e lo gestisce. Se le risorse sono libere, comunica al driver tale evento e gli dice se e' possibile o no proseguire in base alle risorse disponibili. Il driver aggiorna i buffer della scheda per visualizzare il menu, quindi, perche' e' il sistema operativo che gli ha detto che la risorsa "buffer della scheda" e' libero. E non viceversa.
Sirus, il concetto di fondo e' sbagliato. Dopo l'hardware non c'e' il driver come hai messo nello schema ma l'SO e subito dopo i driver. C'e' un inversione nello schema quindi un errore di concetto findamentale. Un driver gestisce un dispositivo le cui risorse vanno gestite dal sistema operativo. Un hard disk viene gestitio dal driver in lettura/scrittura, ma e' il sistema operativo che dice al driver quando puo' scrivere/leggere. E' il sistema operativo che astrae l'hardware al resto del sistema. Astrarre l'hardware significa proprio controllare in che modo le altre risorse possano essere condivise/gestite e questo avviene fornendo al mondo esterno un'API di basso livello, con cui, appunto, vengono scritti i driver. I driver sono effettivamente una pezzo del sistema operativo. Apri i sorgenti del kernel linux. I driver (i moduli) vengono compilati solo dopo aver creato l'immagine del sistema operativo, cioe' quindi solo dopo aver compilato i pezzi del sistema operativo che implementano queste API e dal quale si possono generare i moduli del kernel.
Quello che ha detto Vicius e' semplicemente la realta' dei fatti. E da quelle 4 parole si evince l'infattibilita' della cosa... Senza dimenticare che si sta scambiando lo user space e la user mode neanche fossero la stessa cosa ;)
Qundo clicchi il bottone Start, si emette un evento. Questo evento, gestito dall'API win32, viene gestito dall'API. L'API gestisce tale evento ed emette un segnale che invia al sistema operativo. Il sistema operativo raccoglie tale segnale e lo gestisce. Se le risorse sono libere, comunica al driver tale evento e gli dice se e' possibile o no proseguire in base alle risorse disponibili. Il driver aggiorna i buffer della scheda per visualizzare il menu, quindi, perche' e' il sistema operativo che gli ha detto che la risorsa "buffer della scheda" e' libero. E non viceversa.
Sirus, il concetto di fondo e' sbagliato. Dopo l'hardware non c'e' il driver come hai messo nello schema ma l'SO e subito dopo i driver. C'e' un inversione nello schema quindi un errore di concetto findamentale. Un driver gestisce un dispositivo le cui risorse vanno gestite dal sistema operativo. Un hard disk viene gestitio dal driver in lettura/scrittura, ma e' il sistema operativo che dice al driver quando puo' scrivere/leggere. E' il sistema operativo che astrae l'hardware al resto del sistema. Astrarre l'hardware significa proprio controllare in che modo le altre risorse possano essere condivise/gestite e questo avviene fornendo al mondo esterno un'API di basso livello, con cui, appunto, vengono scritti i driver. I driver sono effettivamente una pezzo del sistema operativo. Apri i sorgenti del kernel linux. I driver (i moduli) vengono compilati solo dopo aver creato l'immagine del sistema operativo, cioe' quindi solo dopo aver compilato i pezzi del sistema operativo che implementano queste API e dal quale si possono generare i moduli del kernel.
Quello che ha detto Vicius e' semplicemente la realta' dei fatti. E da quelle 4 parole si evince l'infattibilita' della cosa... Senza dimenticare che si sta scambiando lo user space e la user mode neanche fossero la stessa cosa ;)
ok lo strato dei driver è "fisicamente" sopra al so (altrimenti come starebbe in esecuzione?!) ma logicamente è frapposto tra hw e so, l'hai detto tu stesso che (se le risorse sono disponibili) il so chiama le primitive dei driver per far funzionare hw :)
scusa un secondo ma quando il so gestisce la cpu, ossia gli dice di eseguire tale operazione, la porzione di codice che "istruisce" la cpu che cavolo è se non un driver :mbe: ?!
MA CHE DICIII!!! naaa, non ci credo manco per niente, in Windows non è assolutamente così!!! se così fosse secondo te come dovrebbe fare un programmatore del kernel di Linux a usare sti drivers tutti completamente diversi tra loro?!? soprattutto quando poi in futuro potrebbero cambiare ulteriormente...
scusa, tu sai cos'è il DDK?
Bhe su Windows esistono le DirectSound se vuoi parlare con una scheda audio e su Linux esistono layer come Alsa. Su Windows ci sono le Direct3D o come cavolo si chiamano ora per parlare con una scheda video e su linux ci stanno le DRI. Ma questi sono layer del kernel che forniscono un'interfaccia comune ai vari driver. Tu però non vuoi usare il kernel e andare direttamente ai driver quindi ti perdi tutte le comodità.
io certe persone proprio non capisco da che parte stanno :D
Dovrei sputare nel piatto in cui mangio ? :D
ciao ;)
Ciao a tutti
mi inserisco in questo discorso perchè mi interessa particolarmente dato che sto preparando l'esame di sistemi operativi.
Siccome si sta parlando di linux bisogna tener conto di come è struttura questo sitema operativo
http://img276.echo.cx/img276/618/driverinterface6hz.gif (http://www.imageshack.us)
da questa immagine si capisce che i driver fanno parte del kernel (che è il rettangolo tratteggiato) e dunque non stanno ne sopra ne sotto il SO. Un programma utente (quelli rappresentati dalla P) possono interagire con i driver solo attraverso le system calls.
per cui mi sembra impossibile la possibilità di far fare a wine, che gira come processo utente, una chiamata diretta ai drivers.
strano che linux non permette una cosa del genere (ammetto però di non conoscere propriamente la struttura del kernel linxu, ma quella di un so in generale)
però è confermata la mia tesi quindi...sono le primitive del SO (API) che interagiscono con i driver che poi istruiscono HW.quindi il primo strato di kernel a diretto contatto con HW sono proprio i driver :)
ok lo strato dei driver è "fisicamente" sopra al so (altrimenti come starebbe in esecuzione?!) ma logicamente è frapposto tra hw e so, l'hai detto tu stesso che (se le risorse sono disponibili) il so chiama le primitive dei driver per far funzionare hw :)
scusa un secondo ma quando il so gestisce la cpu, ossia gli dice di eseguire tale operazione, la porzione di codice che "istruisce" la cpu che cavolo è se non un driver :mbe: ?!
Il discorso e' questo. Nel tuo schema, manca un filo che induce una dipendenza circolare fra hw <--> SO <--> Driver. Tu hai messo che dall'HW si va al driver e dal driver si va all'SO. In realta' lo schema e': Dall'hardware viene caricato una porzione minimale di servizi dell'SO, poi da li i driver tornano indietro a comunicare all'hardware tramite il diretto controllo del SO. Fatti lo schemino a mente non mi va di disegnarlo. Quello che dici e' giusto, infatti. Pero' bisogna tenere in considerazione che il driver controlla un dispositivo solo se l'SO da il "via libera", altrimenti le risorse chi le dovrebbe gestire? :p Chiaramente il driver, poi, gestendo l'hardware nel suo funzionamento, ritorna degli stati all'SO. C'e' una sorta di dipendenza circolare. Al momento che si spezza la catena i conti non tornano piu' ;)
Non si puo' accedere ad un driver senza passare per il sistema operativo, proprio perche' il driver per funzionare necessita dei servizi che mette a disposizione l'SO. Poi WINE e' un'implementazione dell'API Win32. Funziona a segnali e eventi. Gli eventi vengono gestiti dall'API stessa andando a "ritroso" in un modello a cascata (di eventi), che controllano praticamente tutto (allocazione di memoria, creazione di nuovi thread, allocazione di altre risorse, lettura, scrittura..). Scavalcando l'SO a queste cose chi ci pensa, il driver della scheda video? ;)
strano che linux non permette una cosa del genere (ammetto però di non conoscere propriamente la struttura del kernel linxu, ma quella di un so in generale)
però è confermata la mia tesi quindi...sono le primitive del SO (API) che interagiscono con i driver che poi istruiscono HW.quindi il primo strato di kernel a diretto contatto con HW sono proprio i driver :)
E' questo che sto cercando di dire da 80 thread :doh: Pero' se noti, il driver agisce solo tramite system call, quindi non puoi scavalcare il kernel. In difinitiva il driver controlla il dispositivo SOLO mediante AUTORIZZAZIONE del SISTEMA OPERATIVO. Quindi il sistema operativo e' a un livello piu' basso ancora del driver, che deve usare sulle sue SPALLE i servizi dell'SO.
Ecco perche' tutto quello che si sta discutendo di WINE non ha senso, non ha un minimo di cognizione di causa e soprattutto non sta ne in cielo ne in terra ne' come rigore progettuale ne' rigore fisico di una macchina.
Ma pensate veramente di voler buttare con 4 parole al cesso il lavoro di centinaia di programmatori che ci hanno lavorato anni dicendo che l'architettura di WINE si puo' stravolgere in questo modo? Suvvia, un po' i piedi per terra ... ;)
ragazzi vi faccio i complimenti, nemmeno nello juventus clan si riescono a fare 3 pagine di OT consecutivo :ave:
cmq non c'e' problema, io la notizia l'ho data :)
ribadisco il rammarico per averlo scoperto cosi tardi ma ormai...
per quanto riguarda i progetti la scadenza del 14 credo sia per l'approvazione ma in giro (ad esempio nel sito di JXTA) ho visto delle proposte gia' pronte, credo si tratti solo di scrivere qualche pagina per dettagliare bene quello che si vuol fare durante l'estate
se qualcuno riesce a partecipare tanto meglio ma cmq, anche senza i 4500 dollari, programmare open source e' sempre bene. magari nel tempo libero, con calma... :)
ragazzi vi faccio i complimenti, nemmeno nello juventus clan si riescono a fare 3 pagine di OT consecutivo :ave:
cmq non c'e' problema, io la notizia l'ho data :)
ribadisco il rammarico per averlo scoperto cosi tardi ma ormai...
per quanto riguarda i progetti la scadenza del 14 credo sia per l'approvazione ma in giro (ad esempio nel sito di JXTA) ho visto delle proposte gia' pronte, credo si tratti solo di scrivere qualche pagina per dettagliare bene quello che si vuol fare durante l'estate
se qualcuno riesce a partecipare tanto meglio ma cmq, anche senza i 4500 dollari, programmare open source e' sempre bene. magari nel tempo libero, con calma... :)
Che ci vuoi fare... Magari ci facciamo cambiare il titolo del thread da Cionci in "Nuova teoria delle applicazioni di sistema by 71104: Come aumentare le performance scavalcando il kernel" :rolleyes: :rolleyes: :rolleyes: :asd:
CUT
OK risolto l'inghippo il nostro sistema operativo è un cerchio, ossia il kernel autorizza il driver ma senza il driver il kernel non può lavorare...speriamo di non fargli girare la palle al SO altrimenti siamo fottuti :sofico:
sta di fatto che "Rosetta" che si userà per utilizzare programmi PPC per Mac su Mac con x86 sarà un microkernel che si affiancherà a darwin e permetterà di avere prestazioni elevatissime ;) la strada giusta sarebbe questa anche per WINE altrimenti WINE è effettivamente un emulatore e nulla di più.
imho ci vorrebbe un interprete a questo punto, un progetto tutto nuovo in grado di sostituire WINE ;)
ragazzi vi faccio i complimenti, nemmeno nello juventus clan si riescono a fare 3 pagine di OT consecutivo :ave:
cmq non c'e' problema, io la notizia l'ho data :)
ribadisco il rammarico per averlo scoperto cosi tardi ma ormai...
per quanto riguarda i progetti la scadenza del 14 credo sia per l'approvazione ma in giro (ad esempio nel sito di JXTA) ho visto delle proposte gia' pronte, credo si tratti solo di scrivere qualche pagina per dettagliare bene quello che si vuol fare durante l'estate
se qualcuno riesce a partecipare tanto meglio ma cmq, anche senza i 4500 dollari, programmare open source e' sempre bene. magari nel tempo libero, con calma... :)
voi gobbacci non dovete parlare :asd: :sofico:
OK risolto l'inghippo il nostro sistema operativo è un cerchio, ossia il kernel autorizza il driver ma senza il driver il kernel non può lavorare...speriamo di non fargli girare la palle al SO altrimenti siamo fottuti :sofico:
Esatto. Che succede se spezzi la catena? ;)
sta di fatto che "Rosetta" che si userà per utilizzare programmi PPC per Mac su Mac con x86 sarà un microkernel che si affiancherà a darwin e permetterà di avere prestazioni elevatissime ;) la strada giusta sarebbe questa anche per WINE altrimenti WINE è effettivamente un emulatore e nulla di più.
imho ci vorrebbe un interprete a questo punto, un progetto tutto nuovo in grado di sostituire WINE ;)
Come ti ha detto Vicius, rosetta non e' altro che un interprete just in time. Le sue prestazioni elevatissime come dici sono tutte da verificare, perche' per raggiungere quegli scopi ci sono i seguenti fattori:
1) Si usano i fat binaries, cioe' binari enormi che contengono codice oggetto sia x86 che PPC (quindi Rosetta non e' l'unico componente). I binari sono enormi proprio perche' contengono lo stesso programma 2 volte (una versione x86 e una PPC). Immagina l'overhead che ha quel povero loader.
2) E' una porzione di microkernel che effettua traduzioni on the fly, quindi ha molte risorse da consumare.
3) Va aggiunto l'overhead ineliminabile che caratterizza tutte le architetture a microkernel. Cioe' Rosetta dovrebbe tradurre "il da farsi da PPC a X86" e poi comunicare a Darwin il lavoro da svolgere...
Io attenderei qualche analisi valutazionale per le prestazioni, su cui personalmente non credo eccessive :p Rimane comunque un layer di compatibilita'. Gli informatici chiamano queste cose "hack" cioe' soluzioni che funzionano ma non eccessivamente eleganti. :p In definitiva, prima sparisce il codice PPC e meglio e' :D
Se poi vogliamo fare alla 71104, "secondo me sara' molto piu' lento perche' ci saranno una sacco di chiamate in piu' fra CALL e CMP" :asd: :asd: :asd:
Ehhhh l'analisi della complessita'... Povero Donald Knuth... Se sentisse :asd:
Ascolta, la finisci subito o ti segnalo ad un moderatore? fai pure lo spritoso?
Vedi di usare un tono rispettoso. non fare agli altri ciò che non vuoi sia fatto a te: se tu offendi la mia intelligenza io offendo tua madre.
Implementare la WIN32 API senza passare per il Kernel...
Analisi computazionale fatta a mente
Chiamare i driver senza passare per il sistema operativo neanche i driver funzionassero per mano dello Spirito Santo
Compiti da sistema operativo dentro le API
Pare di stare a vedere un film di Spielberg. vedo che continui a non capirci un pene. ancora una volta ti chiedo (seriamente però): vuoi una spiegazione? oppure se te le scrivo poi continui a prendermi in giro?
Qundo clicchi il bottone Start, si emette un evento. Questo evento, gestito dall'API win32, viene gestito dall'API. L'API gestisce tale evento ed emette un segnale che invia al sistema operativo. delirio...
Il sistema operativo raccoglie tale segnale e lo gestisce. Se le risorse sono libere, comunica al driver tale evento e gli dice se e' possibile o no proseguire in base alle risorse disponibili. Il driver aggiorna i buffer della scheda per visualizzare il menu, quindi, perche' e' il sistema operativo che gli ha detto che la risorsa "buffer della scheda" e' libero. E non viceversa. o hai spiegato male o è delirio anche questo; comunque non è detto che siano sempre i drivers a interrogare il SO, è ovvio che avviene anche il contrario: tramite interfacce ben definite (delle quali VICIUS non sembra conoscere l'esistenza) i drivers e il SO comunicano tra di loro sia in un verso che nell'altro.
Sirus, il concetto di fondo e' sbagliato. no, aveva solo qualche giusta semplificazione.
Dopo l'hardware non c'e' il driver come hai messo nello schema ma l'SO e subito dopo i driver. come fa il SO ad interporsi tra i drivers e l'hardware? è il SO secondo te che fa I/O sulle periferiche? gagliardo, e i programmatori del kernel di Linux dove le hanno prese le specifiche universali di tutto l'hardware del mondo (anche futuro)?
C'e' un inversione nello schema quindi un errore di concetto findamentale. bla bla bla puttanate; ripeto ancora che c'era solo qualche giusta semplificazione.
Un driver gestisce un dispositivo le cui risorse vanno gestite dal sistema operativo. Un hard disk viene gestitio dal driver in lettura/scrittura, ma e' il sistema operativo che dice al driver quando puo' scrivere/leggere. se tu fai uno schema del genere (il SO gestisce i drivers e quindi sta "sotto") lo posso anche accettare, ma poi sotto ancora non mi ci puoi mettere l'hardware (l'hardware gestisce il SO?). i drivers fanno comunque operazioni di I/O sulle periferiche, gestiscono le interrupt e le memory ranges dedicate all'hardware, quindi in qualsiasi schema stanno per forza di cose a contatto con la parte hardware.
E' il sistema operativo che astrae l'hardware al resto del sistema. lo fa tramite i drivers
Astrarre l'hardware significa proprio controllare in che modo le altre risorse possano essere condivise/gestite e questo avviene fornendo al mondo esterno un'API di basso livello, con cui, appunto, vengono scritti i driver. qui hai confuso le risorse hardware col modo in cui il SO le rappresenta al suo interno
I driver sono effettivamente una pezzo del sistema operativo. nnnoooooooo O_O
UNA frase giusta alla fine sono riuscito a trovarla!! temevo di non trovarne nessuna... peccato che non è tanto lunga :-\
Apri i sorgenti del kernel linux. I driver (i moduli) vengono compilati solo dopo aver creato l'immagine del sistema operativo, cioe' quindi solo dopo aver compilato i pezzi del sistema operativo che implementano queste API e dal quale si possono generare i moduli del kernel. tu hai ben chiaro il concetto di quello che in Windows si chiama DDK; VICIUS invece no, però ha la parte opposta dello schema (quella che manca a te); dovreste unirvi per avere le idee chiare.
Quello che ha detto Vicius e' semplicemente la realta' dei fatti. E da quelle 4 parole si evince l'infattibilita' della cosa... Senza dimenticare che si sta scambiando lo user space e la user mode neanche fossero la stessa cosa ;) io non so cos'è lo User Space, so solo cos'è la User Mode; dimmelo tu cos'è lo User Space.
Tu ragazzo non hai concezione di causa mi spiace. Possiamo interrompere qui' la discussione. La differenza fra me e te e' che io spiego e motivo, tu piu' di mettere "delirio" non dai :asd: :asd: Dopo che hai detto "mia madre" ti ho segnalato al moderatore. Lui provvedera' se vogliono fare qualcosa. Io me ne disinteresso e mi disinscrivo da questa discussione con bambini che si improvvisano architeti del software. :asd: :asd:
Consiglio: Se non sai cos'e' lo user space, leggiti un buon libro di sistemi operativi. Magari scopri il non senso che porti avanti :asd: :asd: :asd:
Ricordati che io non ho offeso nessuno. Il piede di guerra lo hai portato avanti tu anche con offese pesanti. Io non mi metto a litigare con bambini che ancora terminano di studiare la pagina 10 del proprio libro di SO :asd: :asd: :asd:
Comunque se non ti vergogni tu, contenti tutti :sofico:
se fosse proprio come dici tu, quando il SO deve visualizzare una modifica del desktop che fa?!
invece i driver si posizionano ad uno strato logicamente inferiore (poi sono dei programmi e per essere un esecuzione necessitano del SO ;) ) inquanto quando c'è una pressione sul pulsante start (per esempio) windows reagisce dicendo al driver video di istruire la vga in modo da far comparire il menù...
quindi vedi che è il SO che chiama le primitive dei driver ;) è anche il contrario cmq: comunicano in tutti e due i versi. in Windows i drivers usano le interfacce kernel mode esportate dal SO ad es. per gestire files, memoria, IPC, componenti del SO quali l'IO Manager, la struttura dei processi, ecc.
Tu ragazzo non hai concezione di causa mi spiace. tu nonnino sei un gran paravento mi spiace.
Possiamo interrompere qui' la discussione. no problem.
La differenza fra me e te e' che io spiego e motivo, tu piu' di mettere "delirio" non dai :asd: :asd: una sola volta ho messo "delirio", tutte le altre ho spiegato, motivato, e portato in campo le mie argomentazioni; tu invece hai quasi sempre sfottuto con le tue farciture di "asd", "rotfl" e "rolleyes".
EDIT: un paio di volte ti ho anche chiesto se effettivamente volevi una spiegazione; risposte: "asd", "rotfl" e "rolleyes".
EDIT2: ma l'hai riletta la frase alla quale ho scritto "delirio"? cioè, secondo te quella roba non è delirio?!? massù...!!!
Dopo che hai detto "mia madre" ti ho segnalato al moderatore. sei andato a piangere dalla maestra? manco fossi un bambino...
Lui provvedera' se vogliono fare qualcosa. Io me ne disinteresso e mi disinscrivo da questa discussione con bambini che si improvvisano architeti del software. :asd: :asd: cvd
Consiglio: Se non sai cos'e' lo user space, leggiti un buon libro di sistemi operativi. Magari scopri il non senso che porti avanti :asd: :asd: :asd: perché non me lo spieghi tu anziché continuare a premere le stesse prime tre lettere della terza fila di tasti? (o quarta se conti anche i tasti F)
Ricordati che io non ho offeso nessuno. no, infatti, non hai offeso proprio nessuno, già...
Il piede di guerra lo hai portato avanti tu anche con offese pesanti. si, scempiaggini: il flame l'hai iniziato tu (e l'hai finito da vero uomo, non c'è che dire...).
Io non mi metto a litigare con bambini che ancora terminano di studiare la pagina 10 del proprio libro di SO :asd: :asd: :asd: no, infatti tu stai ben lontano dal bambino cattivo, la mamma te lo dice sempre.
qui la discussione degenera e nessuno parla con cognizione di causa
o hai spiegato male o è delirio anche questo; comunque non è detto che siano sempre i drivers a interrogare il SO, è ovvio che avviene anche il contrario: tramite interfacce ben definite (delle quali VICIUS non sembra conoscere l'esistenza) i drivers e il SO comunicano tra di loro sia in un verso che nell'altro.
Tu hai detto più volte che vuoi saltare il kernel linux quindi non puoi usare i layer che mette a disposizione. Le DDK sono come ALSA o DRI. Un interfaccia comune che il so usa/mette a disposizione per accedere all'hardware. Ma se non sbaglio tu proprio questo vuoi evitare. giusto?
come fa il SO ad interporsi tra i drivers e l'hardware? è il SO secondo te che fa I/O sulle periferiche? gagliardo, e i programmatori del kernel di Linux dove le hanno prese le specifiche universali di tutto l'hardware del mondo (anche futuro)?
Non è proprio a questo che serve la parte di gestione I/O di un kernel ? :confused:
Almeno quando ho fatto sistemi operativi avevo capito cosi.
tu hai ben chiaro il concetto di quello che in Windows si chiama DDK; VICIUS invece no, però ha la parte opposta dello schema (quella che manca a te); dovreste unirvi per avere le idee chiare.
Vedremo di incontrarci davanti ad una birretta allora. :D
ciao ;)
Tu hai detto più volte che vuoi saltare il kernel linux quindi non puoi usare i layer che mette a disposizione. Le DDK sono come ALSA o DRI. Un interfaccia comune che il so usa/mette a disposizione per accedere all'hardware. Ma se non sbaglio tu proprio questo vuoi evitare. giusto? aspetta, il DDK non serve ad accedere all'hardware!! l'IO lo fanno i drivers, le istruzioni assembly IN e OUT vengono fatte nel codice contenuto nei device drivers!! le routines esportate da ntdll.dll, hal.dll, ntoskrnl.exe, ecc. servono ad altri compiti che ho elencato brevemente qualche post fa. poi nel DDK sono anche documentate le interfacce che dovrebbero avere i drivers per potersi mettere in comunicazione col sistema operativo (le funzioni esportate dal driver stesso che il sistema operativo deve chiamare insomma).
Non è proprio a questo che serve la parte di gestione I/O di un kernel ? :confused:
Almeno quando ho fatto sistemi operativi avevo capito cosi. la parte di gestione I/O di un SO gestisce l'hardware utilizzando i device drivers; l'unico motivo percui esistono i device drivers, sono le differenze delle specifiche delle periferiche.
Vedremo di incontrarci davanti ad una birretta allora. :D :D :cincin:
qui la discussione degenera e nessuno parla con cognizione di causa un OT per definizione non ha cognizione di causa: io ho aperto apposta un altro thread (sotto suggerimento del pessimo mjordan), ma vedo che pochi se lo filano. il thread sta lì, se vogliamo far diventare IT questo OT che problema c'è? x me va bene!
Passiamo al pratico allora. Basta con questa teoria noiosa. Stiamo andando off topic nell'off topic. Illustraci come scavalcare un kernel e comunicare con i driver con un'applicazione quando sei in user space e puoi usare solo quella perche' e' il kernel che te lo impone. Passiamo al pratico. Passa a DIMOSTRARE che e' possibile. Visto che se ti evidenzio i controsensi ti scaldi. Allora ti chiedo. Abbiamo dei driver. Un kernel. Dobbiamo usare i driver senza passare per l'SO. Come si fa? Illustrami questa somma tecnica. :ave:
aspetta, il DDK non serve ad accedere all'hardware!! l'IO lo fanno i drivers, le istruzioni assembly IN e OUT vengono fatte nel codice contenuto nei device drivers!! le routines esportate da ntdll.dll, hal.dll, ntoskrnl.exe, ecc. servono ad altri compiti che ho elencato brevemente qualche post fa. poi nel DDK sono anche documentate le interfacce che dovrebbero avere i drivers per potersi mettere in comunicazione col sistema operativo (le funzioni esportate dal driver stesso che il sistema operativo deve chiamare insomma)
Quindi vorresti sfruttare l'interfaccia comune definita per permettere al kernel e ai driver di parlare ma facendo in modo di parlare con wine ? Ma a questo punto finiresti per reimplementare X, Alsa, Cups e un infinita di altre cose inutilmente.
ciao ;)
RaouL_BennetH
09-06-2005, 12:47
x 71104:
leggo spesso i tuoi post, con interesse anche, ma davvero, e non prenderla come un'accusa, in questo 3d hai palesemente cominciato tu a scaldarti per non so quali motivi. Guarda tu stesso:
Originariamente inviato da 71104
ok, ok, senti: le mie spalle con questo post hanno quasi toccato terra, quindi dimmi subito una cosa (senza nessuna offesa): vuoi veramente che ti rispondo, oppure ce ne sbattiamo tutti e due e continuiamo a vivere felici e relativamente contenti?
E questo in risposta ad un post di mjordan che non ti toccava minimamente di persona. :confused:
Io ti considero una persona molto preparata, (per quel che può valere la mia stima) ma hai fatto quella sparata che ha generato il tutto e ancora, rileggendola, non ne capisco il perchè. Volete fare entrambi un passo indietro?
DanieleC88
09-06-2005, 13:05
Porca puttana, questa volta mi avete davvero lasciato spiazzato tutti. Nel giro di una giornata mi ritrovo altre tre pagine piene di insulti e discussioni prive di senso! Ma la vogliamo finire qui o continuiamo a far scannare reciprocamente mjordan e 71104? Io direi di segnalare la cosa a cionci e far chiudere definitivamente il thread. La discussione sta degenerando troppo.
P.S.: Basta! WINE è software decente, 71104. Magari potrebbe essere migliore, ma prova tu a:
- implementare le API di Windows COMPLETAMENTE (fin dalle API di Windows 3.1, oltre ai vecchi programmi per DOS) su un sistema operativo RADICALMENTE diverso da Windows;
- gestire un progetto gigantesco, dove centinaia di persone sviluppano contemporaneamente pezzi di codice (chi è che ascolterebbe la proposta di rimodellare tutto solo per guadagnare qualche ciclo di clock?);
- altre cose che ti risparmio per mancanza di tempo e voglia;
E poi: guarda che io con WINE gioco felicemente anche a 4x4 Evolution, Return to castle Wolfenstein (che non sono proprio del livello di "solitario", sai?), e i suddetti giochi funzionano fluidamente, senza il minimo rallentamento.
E, per finire: io questo thread l'ho scoperto solo dopo aver appreso la notizia da un altro sito. Sai qual'era questo sito?
...http://www.winehq.org/!
E meno male che c'è chi sponsorizza lo sviluppo open source, cosa che sicuramente è un passo avanti per il futuro del software, e cosa che una delle più grandi aziende informatiche al mondo (anzi, la più grande) non fa. Be', per essere precisi, non solo non lo fa: lo contrasta anche.
bene...allora chiudiamo pure ;)
Passiamo al pratico allora. Basta con questa teoria noiosa. Stiamo andando off topic nell'off topic. Illustraci come scavalcare un kernel e comunicare con i driver con un'applicazione quando sei in user space e puoi usare solo quella perche' e' il kernel che te lo impone. Passiamo al pratico. Passa a DIMOSTRARE che e' possibile. Visto che se ti evidenzio i controsensi ti scaldi. Allora ti chiedo. Abbiamo dei driver. Un kernel. Dobbiamo usare i driver senza passare per l'SO. Come si fa? che problema c'è? una volta che sei entrato in kernel mode puoi fare tutto; le routines dei drivers le puoi chiamare; tu dirai che "loro non chiamano te", cioè che la comunicazione nell'altro verso non avviene: allora installi dei drivers ausiliari (non legacy drivers ovviamente) che implementano parte del tuo kernel e comunicano col resto del *tuo* kernel (oltre naturalmente a supportare la presenza del kernel principale :p).
Illustrami questa somma tecnica. :ave: a ogni modo la presa per il didietro non può mai mancare eh? tu però non ti segnali da solo ai moderatori, eh?
che problema c'è? una volta che sei entrato in kernel mode puoi fare tutto; le routines dei drivers le puoi chiamare; tu dirai che "loro non chiamano te", cioè che la comunicazione nell'altro verso non avviene: allora installi dei drivers ausiliari (non legacy drivers ovviamente) che implementano parte del tuo kernel e comunicano col resto del *tuo* kernel (oltre naturalmente a supportare la presenza del kernel principale :p).
ma come ci entri in kernel mode?
che problema c'è? una volta che sei entrato in kernel mode puoi fare tutto; le routines dei drivers le puoi chiamare; tu dirai che "loro non chiamano te", cioè che la comunicazione nell'altro verso non avviene: allora installi dei drivers ausiliari (non legacy drivers ovviamente) che implementano parte del tuo kernel e comunicano col resto del *tuo* kernel (oltre naturalmente a supportare la presenza del kernel principale :p).
Quindi alla fine useresti degli hook per permettere l'accesso delle funzioni interne del kernel ad applicazioni in user-space. Bruttissima idea soprattutto per quanto riguarda la sicurezza. Non oso immaginare cosa potrebbero fare gli altri programmi al kernel sfruttando quelle funzioni.
ciao ;)
x 71104:
leggo spesso i tuoi post, con interesse anche, ma davvero, e non prenderla come un'accusa, in questo 3d hai palesemente cominciato tu a scaldarti per non so quali motivi. Guarda tu stesso: accidenti alla pigrizia... cmq il "senza nessuna offesa" l'avevo scritto apposta per evitare questa ambiguità; adesso sarò franco: nel post immediatamente precedente mjordan non aveva capito niente della mia idea (o almeno mi dava questa impressione) e siccome era assai lunga a spiegarsi ecc. ecc.
E questo in risposta ad un post di mjordan che non ti toccava minimamente di persona. :confused: in realtà nemmeno il mio toccava lui; poi comunque guarda che io gli ho dato diverse possibilità di tornare a discussione pacifica (varie volte gli chiesto di smetterla di prendermi in giro insomma), e lui figurati se la smette...
Io ti considero una persona molto preparata, (per quel che può valere la mia stima) ma hai fatto quella sparata che ha generato il tutto e ancora, rileggendola, non ne capisco il perchè. Volete fare entrambi un passo indietro? ti ringrazio per il complimento, spero di meritarmelo e comunque io rimarrò sempre appassionato alla materia, perciò continuerò sempre a studiare.
mjordan non vuole accettare la mia idea e ancora non è stato capace di dirmi una sola buona ragione tecnica (nei limiti del possibile, visto che si sta parlando di sistemi operativi a livello comunque molto molto generico e astratto); o non ha una mente abbastanza aperta o la sua preparazione è solo una sua illusione condita con qualche termine tecnico; poi certo, può anche essere che sbaglio io e che quello che dico non è fattibile, o forse è fattibile in un SO come Windows, che conosco bene, ma non in Linux che conosco poco e niente. mi pare difficile, visto che stiamo discutendo a livello molto astratto, ma a ogni modo le sue argomentazioni dove stanno? sono i "rotfl", gli "asd", e alcune mistificazioni*?
* mi riferisco al suo schema di Dr-->SO-->HW; poi alla fine mi pare che sirus e mj. abbiano risolto la loro incongruenza: l'esempio della catena calza abbastanza; mj. dice "che succede se io spezzo la catena"? io rispondo "e chi la spezza, se ne crea un'altra". poi se vogliamo mettere da parte le metafore cretine ed entrare in dettagli tecnici, se vogliamo fatti e non pugnette, con Linux non vi posso aiutare, io posso parlarvi solo di Windows e x86.
e ora fatemi andare a vedere i Simpsons, che non ho manco mangiato :D :Prrr:
Quindi alla fine useresti degli hook per permettere l'accesso delle funzioni interne del kernel ad applicazioni in user-space. Bruttissima idea soprattutto per quanto riguarda la sicurezza. Non oso immaginare cosa potrebbero fare gli altri programmi al kernel sfruttando quelle funzioni. gli "hook" come li chiami tu sono sempre in kernel mode (i drivers ausiliari di cui parlo non lavorano in user mode) e sono accessibili solo dalla parte kernel mode, ovvero dalla parte che ha il permesso di effettuare uno switch tra le due modalità. negli x86 lo swith viene controllato dai call gate, i quali a loro volta vengono controllati dal SO (il segmento di codice che effettua la chiamata al call gate deve avere i permessi necessari per entrare in kernel mode).
a questo punto si tratta quindi solo una questione di averceli i permessi necessari: la parte dell'installazione di tutto questo sistema l'ho trascurata (:p :p :p), ma basta avere i permessi di Admin: come installi un driver installi tutto il resto. d'altra parte mi sembra pure giusto: se non sei admin non puoi mica installare tutto quello che ti pare sulla macchina :D
mjordan non vuole accettare la mia idea e ancora non è stato capace di dirmi una sola buona ragione tecnica (nei limiti del possibile, visto che si sta parlando di sistemi operativi a livello comunque molto molto generico e astratto);
secondo me qui tu sbagli perchè la discussione è nata da una tua critica ad un software fatto per linux per cui la discussione non è teorica ma è strettamente leagata a questo SO.
che problema c'è? una volta che sei entrato in kernel mode puoi fare tutto; le routines dei drivers le puoi chiamare; tu dirai che "loro non chiamano te", cioè che la comunicazione nell'altro verso non avviene: allora installi dei drivers ausiliari (non legacy drivers ovviamente) che implementano parte del tuo kernel e comunicano col resto del *tuo* kernel (oltre naturalmente a supportare la presenza del kernel principale :p).
Cioe' tu vuoi implementare un semi sistema operativo per fare un'implementazione di un'API WIN32 :eek: A sto punto ti riscrivi Windows :sofico: Quello che vuoi fare esiste gia', ReactOS, un'implementazione di Windows nativa. Le routines dei driver come le chiami? :muro: Mica hanno un'interfaccia pubblica richiamabile :muro: I driver vanno usati dal sistema oerativo, come le chiami le "routine dei drivers". Pare che vuoi usare i drivers come se fossero API :muro: Spiegati meglio, fornisci esempi. Non soltanto teorie. Te lo stanno dicendo tutti che e' una c@g@a@ di idea. Io ti sto dicendo che e' infattibile e tu spari merda su di me. Allora ti chiedo. DIMOSTRAMI che si puo' fare. Ti giuro che se me lo dimostri vado dicendo sullo stesso forum che io sono una merda di me' stesso. Pero' mi devi dimostrare. Fino ad adesso stai parlando soltanto.
a ogni modo la presa per il didietro non può mai mancare eh? tu però non ti segnali da solo ai moderatori, eh?
Scusa eh. Ma ti spacci per quello che SCOPRE (neanche inventa) una nuova architettura di un programma che esiste da anni a cui ci hanno lavorato centinaia di teste. Mi dici che non lavoreresti per il progetto WINE perche' hai altri obiettivi neanche fossi Linus Torvalds che rifiuta i posti di lavoro alla Apple, ogni commento hai una tua motivazione controversa neanche la teoria dei sistemi operativi l'avessi inventata tu e, come se non bastasse, parli di un programma per LINUX descrivendo continuamente l'architettura di WINDOWS. Permetti che causa ilarita' la cosa.
Dunque, mi trovo in imbarazzo a gestire questo thread, in quanto vedo che vi è stato quello che posso definire un "prolungato scambio di cortesie".
L'unico intervento che ritengo possibile è:
1) chiedere L'IMMEDIATA E NON DISCUTIBILE cessazione delle ostilità e un sano periodo di "raffreddamento" in cui i due utenti interessati si dovranno limitare a postare UNICAMENTE in relazione al topi ed agendo come se la controparte NON ESISTA. In difetto di ciò scatterà una sospensione.
2) ricordare che leggere il regolamento non è nocivo per la salute.
3) ricordare che gli insulti via PVT sono puniti secondo regolamento e gli insulti in mail sono puniti dalla Legge Italiana.
Insomma, DATECI UN TAGLIO!
["Dacci un taglio" è un servizio di pubblica utilità fornito dallo staff di Moderazione di HWUPgrade]
http://www.albisole.it/inser/images/dacciuntagliologo.jpg
Posso permettermi di dirti che hai usato lo stile piu' elegante per cessare una discussione mai visto prima d'ora in un forum di discussione? :sofico:
Bello mi piace. Ci esce pure la risata. :D
Io quello che avevo da dire l'ho detto, mi ritiro ai miei libri che oggi mi avete fato perdere troppo tempo. :Prrr: E l'esame e' vicino.
P.S.: Se c'e' qualche nomina per qualche premio Turing chiamatemi che voglio partecipare. ;)
Insomma, DATECI UN TAGLIO!
["Dacci un taglio" è un servizio di pubblica utilità fornito dallo staff di Moderazione di HWUPgrade]
http://www.albisole.it/inser/images/dacciuntagliologo.jpg
Geniale :D
Peccato che sia degenerata perche' sono entrambi molto preparati.
Provo a trarre dalla discussione qualche spunto piu' generale. Senza entrare nel merito di come WINE e Linux funzionano perche' non sono particolarmente preparato su entrambi, secondo me 71104 sbaglia l'approccio al problema da un punto di vista Ingegneristico, piu' che tecnico. Dal punto di vista tecnico mi sembra che quello che propone sia fattibile.
L'errore e' piuttosto comune: 71104 propone una modifica del design dell'architettura di WINE con lo scopo di migliorare le prestazioni dell'applicazione. In se' questo non e' un errore, l'errore nasce nel momento in cui il miglioramento delle prestazioni non e' supportato da dati evidenti e incontrovertibili che derivano dal profiling dell'applicazione. Semplici numeri.
Mi spiego meglio: abbiamo in gioco tre sistemi Kernel (K), Wine (W), Driver Layer (D).
L'architettura attuale a quanto ho capito e' di questo tipo:
W -> K -> D
71104 propone questa:
W -> K -> D
W -> D
Ovvero WINE salterebbe per alcuni servizi che accedono alle periferiche il livello di astrazione fornito dal Kernel per accedere direttamente ai Driver. Per altri servizi non critici immagino accederebbe ancora al Kernel per non dover reinventare la ruota (inutile riscrivere codice gia' scritto e testato). Analizziamo (alla buona) la complessita' delle due archietture calcolando il "coupling" del sistema. Per "coupling" si intende un'entita' che dipende direttamente dall'interfaccia di un'altra entita'. Nella prima architettura WINE dipende dal Kernel (1), che fornisce un livello di astrazione rispetto ai driver e quindi e' in coupling con loro (1). Il coupling totale e' 2 (non sono tanto rigoroso, ma e' per capirci). Nella seconda architettura abbiamo WINE che dipende dal Kernel (1) e dai driver (1), il Kernel che dipende dai driver (1). Il coupling totale e' 3, quindi la seconda architettura e' piu' complessa della prima.
In parole, WINE nella seconda architettura dipende direttamente sia dall'interfaccia del Kernel, sia dall'interfaccia dei driver, se cambia per qualche motivo una delle due, WINE deve modificarsi di conseguenza. Nella prima architettura WINE dipende solo dal Kernel, se l'interfaccia dei driver cambia, il Kernel deve cambiare implementazione, ma la sua interfaccia esterna si mantiene stabile (se non si mantenesse stabile chi scrive il Kernel dovrebbe autoflagellarsi), quindi WINE non dev'essere modificato. Aggiungiamo poi che l'interfaccia di un Kernel e' relativamente molto piu' stabile dell'interfaccia dei driver perche' si pone ad un livello di astrazione superiore.
Quindi 71104 propone di aumentare la complessita' del sistema in favore di un aumento prestazionale. In se' non sarebbe sempre e comunque una cosa negativa da fare, a volte e' una scelta necessaria e intelligente, ma stiamo pagando in termini di complessita' qualcosa e questo qualcosa deve essere dimostrato ripagare la spesa. Nessuno pagherebbe per una macchina che il commerciante ci giura accendersi, ma non ci ha mai mostrato.
La regola generale e': si favorisce sempre e comunque la semplicita' del design e dell'implementazione, a meno che non esistano dati precisi e incontrovertibili che dimostrano la necessita' di un'ottimizzazione, e esista un requisito che la richieda.
In inglese: "Early optimazation is the root of all evil".
DanieleC88
10-06-2005, 14:22
Nessuno pagherebbe per una macchina che il commerciante ci giura accendersi, ma non ci ha mai mostrato.
Questo è quello che il povero mjordan sta provando a spiegare da parecchio. Peccato che questo abbia avviato uno scontro tra loro due, perché la discussione era interessante.
P.S.: fek, meriteresti un applauso, come sempre la tua risposta è stata chiara, precisa e professionale! :)
A riguardo da quanto detto da Fek, cito una frase di Andrew Tanembaum, il papa' di Minix e uno dei maggiori esperti di sistemi operativi al mondo, tratta dal suo famosissimo libro:
Operating Systems: Design and implementation" edito da Prentice Hall International, libro che ispiro' Linus Torvalds nella scrittura del primo pezzo di codice del kernel Linux.
Se i programmi dovessero implementare dei servizi che sono pate del sistema operativo, probabilmente la maggior parte di essi non vedrebbe mai la luce
Piu' chiaro di cosi si muore :sofico:
Grande Tanembaum. :D
edito da Prentice Hall International, libro che ispiro' Linus Torvalds nella scrittura del primo pezzo di codice del kernel Linux.
Se gli esempi fossero stati in C++ avrebbe anche ispirato Linux ad impararlo? :P
Se gli esempi fossero stati in C++ avrebbe anche ispirato Linux ad impararlo? :P
Che strano questa mi semrba di averla gia sentita :D
ciao ;)
Grande Tanembaum. :D
Tanembaum è lo stesso che ha detto a Torvalds "nel mio corso di sistemi operativi avresti preso un brutto voto".
scusa un attimo: questo ha scritto un kernel niente male (solo concettualmente "sbagliato") e tu gli dai un brutto voto perché non l'ha fatto come vuoi tu? sta fava :D
vuoi vedere che per prendere 30 bastava dire che minix è figo :asd:
Tanembaum è lo stesso che ha detto a Torvalds "nel mio corso di sistemi operativi avresti preso un brutto voto".
scusa un attimo: questo ha scritto un kernel niente male (solo concettualmente "sbagliato") e tu gli dai un brutto voto perché non l'ha fatto come vuoi tu? sta fava :D
vuoi vedere che per prendere 30 bastava dire che minix è figo :asd:
Indipendentemente da come sono andate le cose, Linux e' il frutto di migliaia e migliaia di persone che sono molto preparate, tenaci e sono nel campo dei sistemi operativi per professione. Francamente ritengo Linus Torvalds un grande, ma anche un culoso della vita. Ho i sorgenti del kernel Linux versione 0.0.1 in un CDROM dove tengo software da collezione, e ti assicuro che Minix a suo rispetto e' un qualcosa di superiore. Che poi la gente ha cominciato a lavorare su Linux perche' aveva il target del sistema professionale e' un altro conto. Ho letto bene le email che si scambiavano Torvalds e Tanembaum, ma sinceramente litigavano per delle questioni inesistenti. Torvalds era molto presuntuoso e diceva che Minix era limitato (e questo e' vero ma non un difetto visto che Minix doveva essere un sistema didattico i cui sorgenti andavano stampati in un libro di Sistemi Operativi), le risposte che dava Tanembaum quindi erano fuori luogo.
Cio' non toglie che un essere umano che scrive un sistema operativo didattico per fare un libro di Sistemi Operativi e' semplicemente un drago. Uno che merita il titolo di "Professore Emerito". Magari avessimo per ogni argomento un qualcosa di implementato. Prendi per esempio il Dragon Book (teoria dei compilatori, di Aho, Sethi e Ullmann), il testo di riferimento per quanto riguarda i compilatori. Un ottimo libro. Autorevole. Preciso. Completo. Un vero reference sotto tutti i punti di vista. Una notazione geniale. Eppure, rimane un libro teorico. Dopo che lo hai letto, conosci anche una forma di linguaggio intermedio per convertire in assembly tutto il lavoro fatto dal compilatore (il three address code), ma un compilatore, purtroppo, non lo sai implementare. Minix e' come se fosse "l'Hello World" dei sistemi operativi. Una cosa geniale. Non ho avuto modo di vedere il suo libro sulle reti, ma su Amazon.com lo definiscono un altro classico di quelli imperdibili. Torvalds e' un grande uomo. Uno che ha sempre preferito il codice alla figa :D , pero' a volte e' troppo presuntuoso. Anche se fino ad adesso come essere il leader di un progetto cosi' grosso lo ha capito bene. Fa fare agli altri e lui si limita semplicemente a scegliere il meglio da includere fra le varie proposte.
Ho letto anche la biografia di Torvalds, il libro "Just for Fun". Si capisce come sia stanco di Linux. Lui stesso dice che se avesse immaginato quante responsabilita' gli portava, non lo avrebbe mai cominciato. Diciamoci la verita'... Chi ci crede a questa affermazione? Probabilmente se lo avesse saputo si sarebbe organizzato diversamente, ma non credo che un software che gli ha portato cosi' tanta fama (e verdoni, visto che adesso si e' comprato una villa a Silicon Valley) non lo avrebbe mai cominciato... ;)
Ci sono tante frasi nel libro che ti fanno capire il suo ego, esaltato fino alla morte. Per l'amor di Dio, se lo puo' permettere di esserlo. Ma io sono uno di quelli che crede che se te lo puoi permettere devono essere gli altri a dirtelo, non stabilirlo tu stesso. Per Linux ha dovuto rinunciare a incarichi importanti ma tutto sommato ora come ora niente puo' dargli fama e gloria come Linux. Non so il numero preciso di sviluppatori che collaborano attivamente a Linux ma so che e' un numero spaventoso. Quando si parla di Linux si pensa a Linus Torvalds, eppure il suo lavoro, seppur geniale, e' minimo rispetto al complesso. Se Linux e' un kernel molto veloce, lo dobbiamo anche a Ingo Molnar che ha inventato uno scheduler O(1), oppure Alan Cox, che da solo scrive 3 volte il codice di Torvalds ed e' "l'uomo" dei driver. Scrive driver per tutto, questo testimonia la sua conoscenza profonda di come funzionano le macchine ad un livello forse un po' fuori dal comune. Oppure al nostro italiano Andrea Arcangeli, che ha scritto tutti gli algoritmi di gestione della VM di Linux... Insomma, Torvalds e' un drago ma anche un fortunato il cui nome troppo spesso aleggia nell'aria anche quando il lavoro e' di qualcun altro. Quindi W TORVALDS ma anche W Tanembaum.
Scusate il post lungo, ma mi sono fatto prendere dalla passione :sofico:
Che strano questa mi semrba di averla gia sentita :D
ciao ;)
Spiegate anche a me? Non ho colto la battuta :sofico:
AnonimoVeneziano
11-06-2005, 08:31
Spiegate anche a me? Non ho colto la battuta :sofico:
fek ha consigliato più volte una riscrittura del kernel linux in C++ :D
fek ha consigliato più volte una riscrittura del kernel linux in C++ :D
E te cosa ci fai qui ?
ciao ;)
DanieleC88
11-06-2005, 09:51
E te cosa ci fai qui ?
Lo vuoi cacciare? :p
Ho letto bene le email che si scambiavano Torvalds e Tanembaum, ma sinceramente litigavano per delle questioni inesistenti. Torvalds era molto presuntuoso e diceva che Minix era limitato (e questo e' vero ma non un difetto visto che Minix doveva essere un sistema didattico i cui sorgenti andavano stampati in un libro di Sistemi Operativi), le risposte che dava Tanembaum quindi erano fuori luogo.
si le ho lette pure io, cercando su google gruppi si trovano ancora
la mia cmq era una battuta, non voglio mancare di considerazione né verso Torvals né verso Tanembaum.
solo che si beccavano come due galletti e la cosa era piuttosto buffa
Non ho avuto modo di vedere il suo libro sulle reti, ma su Amazon.com lo definiscono un altro classico di quelli imperdibili.
beh il libro è fatto bene anche se ho la versione italiana. però quando ne ho dovuto scegliere uno sui sistemi distribuiti ho puntato su altri autori. non esiste solo Tanembaum dopotutto (anche se a livello universitario da noi monopolizza i corsi di SO e reti).
Quindi W TORVALDS ma anche W Tanembaum.
sicuramente
e leggetevi il loro battibecco perché è una figata :asd:
http://groups.google.it/group/comp.os.minix/browse_thread/thread/c25870d7a41696d2/625c4a78723eeef5
Tanembaum è lo stesso che ha detto a Torvalds "nel mio corso di sistemi operativi avresti preso un brutto voto".
E non faccio fatica a crederci :p
Torvalds e' un grande uomo. Uno che ha sempre preferito il codice alla figa :D
Abbiamo gusti diversi, io ho sempre preferito il buon codice e la bella figa :D
fek ha consigliato più volte una riscrittura del kernel linux in C++ :D
Risposta seria adesso. Ormai non penso che il Kernel di Linux debba essere riscritto in C++, sarebbe un lavoro enorme, tanto varrebbe buttare tutto e ripartire da zero, ma anche questo sarebbe impossibile.
Io ho sempre affermato che e' falso che il Kernel di un SO come Linux non possa essere scritto in C++, affermato soprattutto da chi adduce come argomento il fatto che il C++ sarebbe piu' lento del C e presenterebbe un overhead al programmatore. E' falso anche questo, ed e' vero il contrario: spesso e volentieri non e' possibile scrivere codice C veloce, compatto ed efficiente come l'equivalente codice C++, per svariati motivi, fra i quali il fatto che un compilatore C++ "conosce" internamente concetti che un compilatore C non conosce ed e' in grado di usarli per produrre codice piu' ottimizzato. Un esempio potrebbe essere implementare una tabella di dispatch virtuale, oppure ordinare un vettore di elementi dove il tipo degli elementi non e' conosciuto a priori.
E' vero pero' che per chi non conosce il C++ e' piu' facile scrivere codice inefficiente, rispetto a chi non conosce il C. Infatti faccio spesso questa battuta rifermendomi a Torvalds e alla sua famosa affermazione: "Non si puo' scrivere un kernel in C++ perche' in C++ non si possono scrivere allocatori custom". Quando fece quest'affermazione probabilmente non sapeva che in C++ si possono scrivere allocatori custom e sono piu' efficienti che in C. Avrebbe potuto impararlo meglio :p
Abbiamo gusti diversi, io ho sempre preferito il buon codice e la bella figa :D sai apprezzare i piaceri della vita!! :D
ma non sottovalutare le tette!!! :oink: :D :D :D
vabbè, basta va' ^^'
cmq imho il C++ sarebbe perfetto per scrivere un kernel: un kernel normalmente ha necessariamente delle caratteristiche che richiamano immediatamente la OOP, per le quali il C++ è ottimo; ma è anche vero che non è necessario scrivere solo classi, come in Java: in qualunque momento puoi usare variabili e funzioni di livello globale, come tante ce ne sono in un kernel.
il kernel infatti può anche essere implementato in C++, ma le interfacce messe a disposizione dei programmi devono comunque essere C perché non è detto che il programma applicativo che gira sul sistema operativo sia scritto in C++ o in un linguaggio che supporta le classi.
dato che questo thread è andato completamente OT, l'avete provato hurd?? che ne pensate?
sai apprezzare i piaceri della vita!! :D
[...]come in Java: in qualunque momento puoi usare variabili e funzioni di livello globale, come tante ce ne sono in un kernel. [...]
Funzioni e variabili globali sono il male! Meglio evitarle se possibile.
ciao ;)
Funzioni e variabili globali sono il male! Meglio evitarle se possibile.
ciao ;)
Funzioni e variabili globali NON esistono. E NON esistono neppure i Singleton :D
dato che questo thread è andato completamente OT, l'avete provato hurd?? che ne pensate? vabbè ma non esageriamo! almeno nell'OT sii IT! ;) :D
Funzioni e variabili globali sono il male! Meglio evitarle se possibile. eeeehhh??? :confused:
scusa, ora perché funzioni e variabili globali sarebbero dannose?? :confused:
considera che oggi numerosissime librerie (sia in Windows che in Linux) hanno interfacce basate su funzioni globali...
Funzioni e variabili globali NON esistono. E NON esistono neppure i Singleton :D ssssiiiiiii, evvai!!!!! questo thread è stato fin quasi dall'inizio un delirio completo... :)
ssssiiiiiii, evvai!!!!! questo thread è stato fin quasi dall'inizio un delirio completo... :)
il delirio è iniziato con il tuo primo post
ssssiiiiiii, evvai!!!!! questo thread è stato fin quasi dall'inizio un delirio completo... :)
Mi stai dicendo che affermare che un buon design non prevede mai variabili globali e' un delirio? ;)
Lo sai che esistono linguaggi che non ti permettono neppure di definire variabili globali? Alcuni linguaggi come Eiffel arrivano anche a non permetterti di definire in maniera semplice un campo statico di una classe.
Mi stai dicendo che affermare che un buon design non prevede mai variabili globali e' un delirio? ;)
Lo sai che esistono linguaggi che non ti permettono neppure di definire variabili globali? Alcuni linguaggi come Eiffel arrivano anche a non permetterti di definire in maniera semplice un campo statico di una classe. in Java ci sono solo classi, lo so; ma secondo me non è vero che la "globalità" implica necessariamente un design concettualmente errato.
se definisco una variabile globale vuol dire che nel design che ho progettato nella mia testa, il contenuto di quella variabile è concettualmente globale, cioè è accessibile ovunque nell'ambito del modulo corrente. per quale motivo questo implicherebbe che il mio design è errato o non è buono?
in Java ci sono solo classi, lo so; ma secondo me non è vero che la "globalità" implica necessariamente un design concettualmente errato.
se definisco una variabile globale vuol dire che nel design che ho progettato nella mia testa, il contenuto di quella variabile è concettualmente globale, cioè è accessibile ovunque nell'ambito del modulo corrente. per quale motivo questo implicherebbe che il mio design è errato o non è buono?
Perche' non e' un design facile da testare automaticamente :)
theClimber
12-06-2005, 20:46
in Java ci sono solo classi, lo so; ma secondo me non è vero che la "globalità" implica necessariamente un design concettualmente errato.
se definisco una variabile globale vuol dire che nel design che ho progettato nella mia testa, il contenuto di quella variabile è concettualmente globale, cioè è accessibile ovunque nell'ambito del modulo corrente. per quale motivo questo implicherebbe che il mio design è errato o non è buono?
Questo e vero, il design sarebbe buono. E la globalita' non esisterebbe, ma risulterebbe 'contestualizzata' al modulo. E la classe in java puo' essere usata con solo metodi statici per creare un modulo.
Il problema purtroppo e' nell'implementazione dei linguaggi correnti piu' usati (Java, C++ ..), nei quali le classi non sono oggetti veri e propri, ma strutture sintatiche diverse. Quindi usando metodi/variabili globali si perdono le funzionalita' proprie degli oggetti (Ereditarieta', polimorfismo, overloading, override). Inoltre la classe ha un ciclo di vita (ad es. in java deve essere caricata dal classloader in momenti ben precisi, in C++ non entro nei dettagli ...... non e' il mio forte :fagiano: ) che ti limita nel riusarla e nel testarla (come ti ha detto fek)
Non e' detto che tutti i linguaggi devono essere cosi': In smalltalk ad esempio la classe e' un oggetto vero e proprio, i metodi di classe sono normali metodi dell'oggetto e seguono esattamente le stesse regole (ad esempio avrei un istanza della classe String. La classe String e' un oggetto, istanza della classe MetaClass, che e' un oggetto .. etc ... )
Perche' non e' un design facile da testare automaticamente :) perché scusa? :mbe:
[...] Il problema purtroppo e' nell'implementazione dei linguaggi correnti piu' usati (Java, C++ ..), nei quali le classi non sono oggetti veri e propri, ma strutture sintatiche diverse. Quindi usando metodi/variabili globali si perdono le funzionalita' proprie degli oggetti (Ereditarieta', polimorfismo, overloading, override). Inoltre la classe ha un ciclo di vita (ad es. in java deve essere caricata dal classloader in momenti ben precisi, in C++ non entro nei dettagli ...... non e' il mio forte :fagiano: ) che ti limita nel riusarla e nel testarla (come ti ha detto fek) eeehmmmmm... non ho capito una sola parola... o_o''
che vuol dire che le classi non sono oggetti veri e propri? una classe è una cosa, un oggetto un'altra...
ma poi cosa c'entrano le classi e gli oggetti con le funzioni e variabili globali? se dichiaro una cosa come globale non voglio mica usare l'ereditarietà e il polimorfismo su di essa...
e poi ancora devo capire che limitazioni ci sono nel testing; e nel riusarla poi???
Non e' detto che tutti i linguaggi devono essere cosi': In smalltalk ad esempio la classe e' un oggetto vero e proprio, i metodi di classe sono normali metodi dell'oggetto e seguono esattamente le stesse regole (ad esempio avrei un istanza della classe String. La classe String e' un oggetto, istanza della classe MetaClass, che e' un oggetto .. etc ... ) "la classe è un oggetto vero e proprio" temo che sia una frase insensata in qualunque linguaggio... il concetto di classe è diverso dal concetto di oggetto.
eeehmmmmm... non ho capito una sola parola... o_o''
che vuol dire che le classi non sono oggetti veri e propri? una classe è una cosa, un oggetto un'altra...
Vuol dire che in linguaggi come Smalltalk una classe e' a sua volta un oggetto istanza di una metaclasse; puoi creare classi dinamichemente come fossero oggetti, aggiungere e togliere metodi e poi creare oggetti a partire da queste classi, tutto a runtime :)
In altri linguaggio come C# e Java si chiama reflection. In C++ non esiste reflection.
e poi ancora devo capire che limitazioni ci sono nel testing; e nel riusarla poi???
Il primo principio del testing e' che ogni test non influenzi gli altri test, altrimenti il fallimento o il successo di un test puo' dipendere da cose come l'ordine di esecuzione dei test stessi e diverrebbe drammatico gestirli.
Se hai variabili globali usate dai test (oppure oggetti singleton), vuol dire che ogni test ha potenzialmente effetto su gli altri test via le variabili globali e deve ricordarsi di ripristinare il loro valore dopo averle usate. In un progetto grosso diventa molto complicato seguire queste regole e poi capire quando si dimentica di seguirle. E' meglio evitare le variabili globali totalmente; il design ne esce di solito piu' pulito e modulare, piu' semplice e piu' facilmente testabile.
ecco la risposta che mi hai chiesto :) (spero di aver capito bene a quale post ti riferivi; era questo, no?)
Peccato che sia degenerata perche' sono entrambi molto preparati. lui non è preparato, almeno non credo: non scommetterei nulla sulla sua preparazione.
Provo a trarre dalla discussione qualche spunto piu' generale. Senza entrare nel merito di come WINE e Linux funzionano perche' non sono particolarmente preparato su entrambi, secondo me 71104 sbaglia l'approccio al problema da un punto di vista Ingegneristico, piu' che tecnico. Dal punto di vista tecnico mi sembra che quello che propone sia fattibile. come potrebbe non esserlo? si tratta di fare manualmente qualcosa che qualcun altro (Linux) già fa, e si tratta di farlo più velocemente (praticamente uno strato User Mode viene eliminato; vi sembra poco come ottimizzazione?)
L'errore e' piuttosto comune: 71104 propone una modifica del design dell'architettura di WINE con lo scopo di migliorare le prestazioni dell'applicazione. In se' questo non e' un errore, l'errore nasce nel momento in cui il miglioramento delle prestazioni non e' supportato da dati evidenti e incontrovertibili che derivano dal profiling dell'applicazione. Semplici numeri. questo discorso sinceramente e senza offesa mi pare che regga poco, specialmente quando si parla di opensource: per avere un risultato evidente e tangibile basta scrivere uno scheletro di driver e uno scheletro di "processo WINE"; poi fai in modo che il driver veda il processo WINE e che i due abbiano la possibilità di comunicare, installi il driver, fai in modo che il processo WINE abbia il permesso di entrare in kernel mode, e fai qualche prova di comunicazione. a seconda di quanto ci metti a fare il tutto dovresti farti un'idea della complessità del progetto, che secondo me non è eccessivamente elevata a patto che sia soddisfatto il requisito che a lavorarci siano persone che abbiano esperienza in kernel mode in Linux; secondo me se questo requisito è soddisfatto, a fare la prova ci vuole una mezz'ora.
[...] In parole, WINE nella seconda architettura dipende direttamente sia dall'interfaccia del Kernel, sia dall'interfaccia dei driver, se cambia per qualche motivo una delle due, WINE deve modificarsi di conseguenza. è assurdo che cambi l'interfaccia dei drivers; anzi, può anche cambiare, ma quella vecchia deve essere ancora supportata!! se è vero che un produttore di hardware deve riscriversi i driver per ogni periferica che produce ad ogni nuova versione di Linux, allora Linux è semplicemente da buttare!!!
Nella prima architettura WINE dipende solo dal Kernel, se l'interfaccia dei driver cambia, il Kernel deve cambiare implementazione, ma la sua interfaccia esterna si mantiene stabile (se non si mantenesse stabile chi scrive il Kernel dovrebbe autoflagellarsi), a doversi autoflagellare sono i produttori di hardware (ma se voi doveste decidere tra autoflagellarvi e buttare via Linux che scegliereste? :p), perché l'interfaccia viene decisa da chi scrive il kernel.
[...] Quindi 71104 propone di aumentare la complessita' del sistema in favore di un aumento prestazionale. be' guarda, se a lavorarci sono persone esperte di programmazione in kernel mode, l'aumento di complessità è minimo (mentre l'aumento prestazionale rimane sempre notevole).
In se' non sarebbe sempre e comunque una cosa negativa da fare, a volte e' una scelta necessaria e intelligente, ma stiamo pagando in termini di complessita' ribadisco: paghiamo relativamente.
qualcosa e questo qualcosa deve essere dimostrato ripagare la spesa. Nessuno pagherebbe per una macchina che il commerciante ci giura accendersi, ma non ci ha mai mostrato. per dimostrarlo basta poco, giusto qualche prova come quella che ho descritto sopra; anzi, se le persone che ci lavorano sono esperte di programmazione in kernel mode, probabilmente non serve neanche quella.
La regola generale e': si favorisce sempre e comunque la semplicita' del design e dell'implementazione, a meno che non esistano dati precisi e incontrovertibili che dimostrano la necessita' di un'ottimizzazione, e esista un requisito che la richieda. questi dati in questo caso è facilissimo ottenerli; be' almeno lo è relativamente: è chiaro che se arriva uno che non sa nemmeno cosa sia la protezione ma che sa solo ammucchiare qualche riga di C, è chiaro che non può ne' provare la fattibilità della cosa, ne' essere ammesso nel team di sviluppo di un simile progetto :p
In inglese: "Early optimazation is the root of all evil". questi inglesi finora mi sembrano aver affermato un sacco di boiate ^^'
cioè, prima la paura causa la rabbia :D
adesso l'"ottimizzazione precoce" (qualunque cosa sia... :mbe: ) sembra essere diventata la causa di tutti i mali...
i rapporti causa-effetto più sballati li trovano loro :D
secondo loro qualsiasi errore che si possa commettere in programmazione è causato da un'ottimizzazione precoce? se mi dimentico di liberare una variabile in un server tcp/ip e un hackerazzo da 4 soldi sfrutta il memory leak per creare un DoS, è stata colpa di una ottimizzazione? :sofico:
mmmmmaahhhh... :D
Vuol dire che in linguaggi come Smalltalk una classe e' a sua volta un oggetto istanza di una metaclasse; puoi creare classi dinamichemente come fossero oggetti, aggiungere e togliere metodi e poi creare oggetti a partire da queste classi, tutto a runtime :)
In altri linguaggio come C# e Java si chiama reflection. In C++ non esiste reflection. ok, non lo sapevo e ho imparato una cosa nuova, ma cosa c'entra sta roba con le variabili e funzioni globali?
Il primo principio del testing e' che ogni test non influenzi gli altri test, altrimenti il fallimento o il successo di un test puo' dipendere da cose come l'ordine di esecuzione dei test stessi e diverrebbe drammatico gestirli.
Se hai variabili globali usate dai test (oppure oggetti singleton), vuol dire che ogni test ha potenzialmente effetto su gli altri test via le variabili globali e deve ricordarsi di ripristinare il loro valore dopo averle usate. In un progetto grosso diventa molto complicato seguire queste regole e poi capire quando si dimentica di seguirle. E' meglio evitare le variabili globali totalmente; il design ne esce di solito piu' pulito e modulare, piu' semplice e piu' facilmente testabile. a parte che le variabili e funzioni globali capitano raramente (parlo per esperienza, almeno per me è così), comunque basterebbe testare le condizioni dei dati globali e dei singleton dopo l'esecuzione di ciascun test (e anche all'inizio, prima di qualsiasi test). questo potrebbe aumentare la quantità di codice da scrivere, ma non eccessivamente. e comunque secondo me i test aumentano inutilmente il tempo di sviluppo in ogni caso, con o senza roba globale e singleton. ma di questo ne stiamo parlando altrove :)
lui non è preparato, almeno non credo: non scommetterei nulla sulla sua preparazione.
Sei proprio seccante e di una presunzione unica.
Certo, dare del non preparato a me, "progettare" una nuova architettura, dire che l'aumento della complessita' e' minimo e poi sta ancora a imparare la pericolosita' delle variabili globali :D
come potrebbe non esserlo? si tratta di fare manualmente qualcosa che qualcun altro (Linux) già fa, e si tratta di farlo più velocemente (praticamente uno strato User Mode viene eliminato; vi sembra poco come ottimizzazione?)
E' il "piu' velocemente" da cosa viene stabilito? "Elimini" una porzione di kernel e la ficchi dentro un'applicazione (bisognera' comunque farlo, kernel o applicazione qualcuno dovra' pure farlo). Perche' piu' veloce?
questo discorso sinceramente e senza offesa mi pare che regga poco, specialmente quando si parla di opensource:
No, il discorso che fa Fek non regge poco. E' il metodo piu' tecnico possibile a disposizione dell'essere umano per effettuare "un'analisi della complessita'" di un progetto. Il profiling. Credo che Fek si stia riferendo alla complessita' computazionela in questo caso, non soltanto alla complessita' di realizzazione. Quanto a "esperti di programmazione in kernel mode" (che significa poi lo sai solo tu, visto che la kernel mode e' soltanto una modalita' dei processori che utilizzano la protezione della memoria e stabilisce solo cosa puoi o non puoi fare, tutto qui), la complessita' di un progetto e' una cosa che non dipende dall'esperienza di chi ci lavora.
fai in modo che il processo WINE abbia il permesso di entrare in kernel mode, e fai qualche prova di comunicazione.
Come?
a seconda di quanto ci metti a fare il tutto dovresti farti un'idea della complessità del progetto, che secondo me non è eccessivamente elevata a patto che sia soddisfatto il requisito che a lavorarci siano persone che abbiano esperienza in kernel mode in Linux; secondo me se questo requisito è soddisfatto, a fare la prova ci vuole una mezz'ora.
Non e' troppo semplicistico, troppo riduttivo come ragionamento?
be' guarda, se a lavorarci sono persone esperte di programmazione in kernel mode, l'aumento di complessità è minimo (mentre l'aumento prestazionale rimane sempre notevole).
Gia', ecco perche' non hanno mai intrapreso quella strada. Perche erano tutti "esperti di programmazione in kernel mode" :D
ribadisco: paghiamo relativamente.
Come lo sai? Dati, numeri, test? Ancora vedo niente.
per dimostrarlo basta poco, giusto qualche prova come quella che ho descritto sopra; anzi, se le persone che ci lavorano sono esperte di programmazione in kernel mode, probabilmente non serve neanche quella.
Appunto, sono prove non dimostrazioni. Dimostrare e' una delle cose piu' difficili quando si parla di queste cose. Ancora con sti "esperti di programmazione in kernel mode" :D
questi dati in questo caso è facilissimo ottenerli; be' almeno lo è relativamente: è chiaro che se arriva uno che non sa nemmeno cosa sia la protezione ma che sa solo ammucchiare qualche riga di C, è chiaro che non può ne' provare la fattibilità della cosa, ne' essere ammesso nel team di sviluppo di un simile progetto :p
Facilissimo ottenerli... Strano... Sembra sia stata sempre una delle cose piu' difficili da evincere... Comunque... come?
lui non è preparato, almeno non credo: non scommetterei nulla sulla sua preparazione.
Ti assicuro che e' molto preparato. E, per favore, stiamo facendo discorsi seri qui, non stiamo cercando di dimostrare chi ce l'ha piu' lungo e chi e' il programmatore piu' bravo. Lasciamo queste scemenze ai troll che infestano le News e manteniamo questa sezione "trolling free".
come potrebbe non esserlo? si tratta di fare manualmente qualcosa che qualcun altro (Linux) già fa, e si tratta di farlo più velocemente (praticamente uno strato User Mode viene eliminato; vi sembra poco come ottimizzazione?)
Ripeto, e lo ripetero' per tutto il corso del post: quanto potenzialmente ottimizza questa soluzione lo puoi dire solo dopo che hai fatto un'analisi numerica precisa dei colli di bottiglia dell'applicazione, non prima. Dalla mia esperienza e quella di tanti altri, i programmatori sono notoriamente molto scarsi a indovinare i colli di bottiglia; servono tool e dati precisi. Solo dopo, sulla base dei dati, si possono fare valutazioni e proporre dove e come intervenire, non prima.
questo discorso sinceramente e senza offesa mi pare che regga poco, specialmente quando si parla di opensource: [...] a fare la prova ci vuole una mezz'ora.
Falla, e porta i dati. Quel discorso e' l'unico logico.
Se tu lavori in un'azienda seria, vai dal tuo lead, gli proponi una soluzione che aumenta la complessita' per ottimizzare a tuo avviso l'applicazione, e non gli porti i dati concreti della tua analisi, lui te li chiedera'. Se gli rispondi che tanto ci vuole mezz'ora, continuera' a chiederti i dati, se gli rispondi che il suo discorso regge poco, il giorno dopo tu non hai piu' un lavoro. Ho visto la gente cacciata per questo ed anch'io quando ero giovane e inesperto e facevo quei discorso, ho rischiato :)
Per fortuna ho imparato a non farlo piu' e con l'esperienza ho capito che il discorso era sensatissimo: mi e' successo piu' di una volta di ipotizzare un collo di bottiglia, correggerlo e poi... girava piu' lento. Il collo di bottiglia era da un'altra parte e no... il problema non ero io scarso a "indovinare", era il processo stesso di tentare di indovinare ad essere sbagliato.
è assurdo che cambi l'interfaccia dei drivers; anzi, può anche cambiare, ma quella vecchia deve essere ancora supportata!! se è vero che un produttore di hardware deve riscriversi i driver per ogni periferica che produce ad ogni nuova versione di Linux, allora Linux è semplicemente da buttare!!!
Non e' assurdo, infatti: Longhorn cambia totalmente l'interfaccia dei driver, soprattutto di quelli delle schede video, ma l'interfaccia esterna rimane invariata infatti non c'e' bisogno di ricompilare le applicazioni grafiche: fanno chiamate al kernel e queste restano invariate.
Come vedi non e' assurdo.
be' guarda, se a lavorarci sono persone esperte di programmazione in kernel mode, l'aumento di complessità è minimo (mentre l'aumento prestazionale rimane sempre notevole).
L'aumento di complessita' c'e' ed e' stato valutato in maggiore coupling. Come ha detto mjordan, la complessita' di un design misurato dal coupling non dipende ovviamente da chi ci lavora sopra.
per dimostrarlo basta poco, giusto qualche prova come quella che ho descritto sopra; anzi, se le persone che ci lavorano sono esperte di programmazione in kernel mode, probabilmente non serve neanche quella.
Fai quelle prove.
questi dati in questo caso è facilissimo ottenerli; be' almeno lo è relativamente: è chiaro che se arriva uno che non sa nemmeno cosa sia la protezione ma che sa solo ammucchiare qualche riga di C, è chiaro che non può ne' provare la fattibilità della cosa, ne' essere ammesso nel team di sviluppo di un simile progetto :p
Se questi dati sono facilissimi da ottenere, ottienili e poi riparliamo. Senza dati, non si propongono ottimizzazioni oppure si cerca un altro lavoro :)
Nota bene, non ho detto che la tua idea e' sbagliata a priori, ho detto che senza dati precisi, non e' proponibile.
questi inglesi finora mi sembrano aver affermato un sacco di boiate ^^'
cioè, prima la paura causa la rabbia :D
adesso l'"ottimizzazione precoce" (qualunque cosa sia... :mbe: ) sembra essere diventata la causa di tutti i mali...
Quell'inglese e' Dijkstra, prima di affermare che sparava boiate ci penserei un paio di milioni di volte :D
secondo loro qualsiasi errore che si possa commettere in programmazione è causato da un'ottimizzazione precoce? se mi dimentico di liberare una variabile in un server tcp/ip e un hackerazzo da 4 soldi sfrutta il memory leak per creare un DoS, è stata colpa di una ottimizzazione? :sofico:
mmmmmaahhhh... :D
Molti problemi dei programmatori alle prima armi sono la volonta' di ottimizzare il proprio codice prematuramente e complicarne il design, che causa poi moltissimi problemi e calo drastico di produzione e, spesso, un'applicazione piu' lenta :)
lui non è preparato, almeno non credo: non scommetterei nulla sulla sua preparazione.
Non mi sembra il caso di rivolgersi in questo modo a mjordan... mjordan è preparatissimo...forse tu non lo conosci perchè non giri molto da queste parte...
Un consiglio: cerca di essere un po' più umile...
mjordan è preparatissimo...
E' solo un maledetto linux fan :vicini:
questo discorso sinceramente e senza offesa mi pare che regga poco, specialmente quando si parla di opensource: per avere un risultato evidente e tangibile basta scrivere uno scheletro di driver e uno scheletro di "processo WINE"; poi fai in modo che il driver veda il processo WINE e che i due abbiano la possibilità di comunicare, installi il driver, fai in modo che il processo WINE abbia il permesso di entrare in kernel mode, e fai qualche prova di comunicazione. a seconda di quanto ci metti a fare il tutto dovresti farti un'idea della complessità del progetto, che secondo me non è eccessivamente elevata a patto che sia soddisfatto il requisito che a lavorarci siano persone che abbiano esperienza in kernel mode in Linux; secondo me se questo requisito è soddisfatto, a fare la prova ci vuole una mezz'ora.
la possibiltà di comunicare tra i "processo WINE" e i driver esiste senza doverla inventare e si chiamano systen calls.
quello che proponi tu allora è così:
WINE fà una chiamata di sistema(user mode) --> WINE drivers (kernel mode) --> Drivers di periferica (kernel mode)
invece ora è così
WINE fà una chiamata di sistema (user mode) --> Drivers di periferica (kernel mode)
a me sembra che nel tuo schema ci sia un passaggio in più
BountyKiller
13-06-2005, 15:02
P.S.: Basta! WINE è software decente, 71104. Magari potrebbe essere migliore, ma prova tu a:
- implementare le API di Windows COMPLETAMENTE (fin dalle API di Windows 3.1, oltre ai vecchi programmi per DOS) su un sistema operativo RADICALMENTE diverso da Windows;
- gestire un progetto gigantesco, dove centinaia di persone sviluppano contemporaneamente pezzi di codice (chi è che ascolterebbe la proposta di rimodellare tutto solo per guadagnare qualche ciclo di clock?);
- altre cose che ti risparmio per mancanza di tempo e voglia;
quoto, si fa presto a sparlare di un programma....se non vi piace potete sempre mettervi a scriverne uno migliore.....
Ti assicuro che e' molto preparato. E, per favore, stiamo facendo discorsi seri qui, non stiamo cercando di dimostrare chi ce l'ha piu' lungo e chi e' il programmatore piu' bravo. Lasciamo queste scemenze ai troll che infestano le News e manteniamo questa sezione "trolling free". perché uno così preparato come mjordan non sa far comunicare un driver con un altro driver che sta ad un livello inferiore in uno stack di drivers?
e perché qualche decina di post fa in questo thread non hai fatto anche a lui la predica dei troll?
Ripeto, e lo ripetero' per tutto il corso del post: quanto potenzialmente ottimizza questa soluzione lo puoi dire solo dopo che hai fatto un'analisi numerica precisa dei colli di bottiglia dell'applicazione, non prima. Dalla mia esperienza e quella di tanti altri, i programmatori sono notoriamente molto scarsi a indovinare i colli di bottiglia; servono tool e dati precisi. Solo dopo, sulla base dei dati, si possono fare valutazioni e proporre dove e come intervenire, non prima. ma allora non è possibile inventare nessun nuovo tipo di software al mondo: non possiamo analizzarli prima di averli scritti.
Falla, e porta i dati. Quel discorso e' l'unico logico. ho già risposto a chi mi fa discorsi del tipo "se sei così bravo perché non lo fa tu" ecc.
Se tu lavori in un'azienda seria, vai dal tuo lead, gli proponi una soluzione che aumenta la complessita' per ottimizzare a tuo avviso l'applicazione, e non gli porti i dati concreti della tua analisi, lui te li chiedera'. Se gli rispondi che tanto ci vuole mezz'ora, continuera' a chiederti i dati, se gli rispondi che il suo discorso regge poco, il giorno dopo tu non hai piu' un lavoro. Ho visto la gente cacciata per questo ed anch'io quando ero giovane e inesperto e facevo quei discorso, ho rischiato :) be', oddio, lì la situazione è diversa: aldilà di ogni cosa io aspetterei prima di parlar male ad un superiore ^^'
il problema è che a causa di questo fatto ad un superiore non dirò mai quello che penso; però se il superiore mi dice di fare una cosa che ci posso fare? la devo fare ahimè, mi piaccia o no :-\
Non e' assurdo, infatti: Longhorn cambia totalmente l'interfaccia dei driver, soprattutto di quelli delle schede video, ma l'interfaccia esterna rimane invariata infatti non c'e' bisogno di ricompilare le applicazioni grafiche: fanno chiamate al kernel e queste restano invariate. di questo non sapevo a dir la verità :mc: sapevo che in Windows XP a 64 bit l'hanno fatto (e infatti guarda che corredo penoso di drivers che ha e guarda il ritardo con cui è uscito...); se l'hanno fatto anche in Longhorn capisco anche qui il motivo del suo ritardo... :D
Come vedi non e' assurdo. solo perché Microsoft ha il suo bel monopolio e si può cullare sugli allori.
dai su, se st'interfaccia cambia il driver va riscritto, non ci sono santi!!
L'aumento di complessita' c'e' ed e' stato valutato in maggiore coupling. Come ha detto mjordan, la complessita' di un design misurato dal coupling non dipende ovviamente da chi ci lavora sopra. a parte che in parte può anche dipenderlo, comunque penso di essermi espresso male, intendevo dire una cosa molto più ovvia e banale: se chi fa un lavoro ha già avuto esperienza in numerosi lavori simili, grazie alla sua esperienza potrà svolgerlo meglio e più velocemente.
Fai quelle prove. ancora :)
Se questi dati sono facilissimi da ottenere, ottienili e poi riparliamo. Senza dati, non si propongono ottimizzazioni oppure si cerca un altro lavoro :) le persone con un minimo di buon senso un altro lavoro non lo cercano: chiunque può pensare qualsiasi cosa, ma se uno ha il potere di metterti per strada a te e alla tua famiglia devi andarci piano.
Nota bene, non ho detto che la tua idea e' sbagliata a priori, ho detto che senza dati precisi, non e' proponibile. mi va benissimo, ma più volte in questo thread ho avuto occasione di ribadire la natura della mia idea (era solo un'ipotesi!! non voglio farlo per davvero!! :))
Quell'inglese e' Dijkstra, prima di affermare che sparava boiate ci penserei un paio di milioni di volte :D qua mi si continuano a citare illustrissimi sconosciuti e loro illustrissime frasi insensate :mbe:
sei o non sei d'accordo che l'"ottimizzazione prematura" non è la causa di tutti i problemi del mondo inerenti la programmazione?
Molti problemi dei programmatori alle prima armi sono la volonta' di ottimizzare il proprio codice prematuramente e complicarne il design, che causa poi moltissimi problemi e calo drastico di produzione e, spesso, un'applicazione piu' lenta :) che è già diverso da quello che ha detto il tizio, che invece è un'esagerazione :)
cmq questo punto del discorso è abbastanza cretino; direi stop :p
PS: mjordan, ti risponderò col permesso di un moderatore.
Non mi sembra il caso di rivolgersi in questo modo a mjordan... mjordan è preparatissimo...forse tu non lo conosci perchè non giri molto da queste parte...
Un consiglio: cerca di essere un po' più umile... mi rivolgo a mjordan più o meno come lui si è rivolto a me; se parliamo di umiltà certe volte sono umile quanto lui se non di più.
la possibiltà di comunicare tra i "processo WINE" e i driver esiste senza doverla inventare e si chiamano systen calls. ma lo sai quello che ci sta in linux tra una system call e un'istruzione di I/O?
quello che proponi tu allora è così:
WINE fà una chiamata di sistema(user mode) --> WINE drivers (kernel mode) --> Drivers di periferica (kernel mode)
invece ora è così
WINE fà una chiamata di sistema (user mode) --> Drivers di periferica (kernel mode)
a me sembra che nel tuo schema ci sia un passaggio in più perché l'hai fatto male.
quoto, si fa presto a sparlare di un programma....se non vi piace potete sempre mettervi a scriverne uno migliore..... allora perché nessuno riscrive IIS e tanti altri programmi Microsoft?
perché uno così preparato come mjordan non sa far comunicare
qua mi si continuano a citare illustrissimi sconosciuti e loro illustrissime frasi insensate :mbe:
sei o non sei d'accordo che l'"ottimizzazione prematura" non è la causa di tutti i problemi del mondo inerenti la programmazione?
ahi ahi....
io sono al primo anno e mi interesso relativamente poco alla programmazione, ma lui non è un illustre sconosciuto :sofico:
avrai fatto un diavolo di corso sugli algoritmi! (sto supponendo che tu stia studiando informatica o ing informatica)
e questo illustre sconosciuto ha tirato fuori un algoritmo non propriamente inutile quando si parla di grafi http://it.wikipedia.org/wiki/Algoritmo_di_Dijkstra
utile anche per risolvere i giochetti che si trovano in giro
Il complesso degli U2 sta per fare un concerto a Dublino.
Mancano 17 minuti all'inizio del concerto ma, per raggiungere il palco, i membri del gruppo devono attraversare al buio un piccolo ponte, disponendo di una sola torcia elettrica. Sul ponte non possono andare più di due persone per volta. La torcia è essenziale per l'attraversamento, per cui deve essere portava avanti e indietro (non può essere lanciata da una parte all'altra) per consentire a tutti di passare. E tutti sono dalla stessa parte del ponte.
Ciascun componente del complesso cammina a una velocità diversa.
I tempi individuali per attraversare il ponte sono:
- Bono, 1 minuto
- Edge, 2 minuti
- Adam, 5 minuti
- Larry, 10 minuti
Se attraversano in due, la coppia camminerà alla velocità del più lento.
Ad esempio: se Bono e Larry attraversano per primi, quando arrivano dall'altra parte saranno trascorsi 10 minuti. Se Larry torna indietro con la torcia saranno passati altri dieci minuti, per cui la missione sarà fallita.
La risposta al test non prevede alcun "trucco". Si tratta solo di indicare lo spostamento delle persone nell'ordine corretto.
sembra che anni fa sia stato utilizzato per la selezione del personale della ms (il sembra è obbligatorio date le balle che girano, ma non è assolutamente inverosimile).
ahi ahi....
io sono al primo anno e mi interesso relativamente poco alla programmazione, ma lui non è un illustre sconosciuto :sofico:
avrai fatto un diavolo di corso sugli algoritmi! (sto supponendo che tu stia studiando informatica o ing informatica) sono al primo anno di Informatica ma Algoritmi ancora non li ho fatti (stanno al 2° anno mi sembra). lo sconosciuto non l'ho ancora studiato :p
sono al primo anno di Informatica ma Algoritmi ancora li ho fatti (stanno al 2° anno mi sembra). lo sconosciuto non l'ho ancora studiato :p
:eek:
credevo che i programmi fossero dal più al meno tutti uguali...
noi lo abbiamo al primo anno!
che esami avete se non date algoritmi?
scusate l'ot :sofico:
qua mi si continuano a citare illustrissimi sconosciuti e loro illustrissime frasi insensate :mbe:
sei o non sei d'accordo che l'"ottimizzazione prematura" non è la causa di tutti i problemi del mondo inerenti la programmazione?
Edsger Dijkstra è uno dei padri dell'informatica... Mai sentito parlare dell'algoritmo di Dijkstra ?
http://www.cs.utexas.edu/users/EWD/
:eek:
credevo che i programmi fossero dal più al meno tutti uguali...
noi lo abbiamo al primo anno!
che esami avete se non date algoritmi?
scusate l'ot :sofico:
quest'anno ho fatto calcolo differenziale, logica, programmazione 1, architetture 1, inglese, e sto facendo calcolo integrale, fisica 1, programmazione 2 e architetture 2.
perché l'hai fatto male.
fallo tu per capire cosa vuoi fare
ma allora non è possibile inventare nessun nuovo tipo di software al mondo: non possiamo analizzarli prima di averli scritti.
Non ho detto questo. Ho detto che in ambiente lavorativo, prima di proporre un'ottimizzazione di un software che funziona, servono dati precisi e inequivocabili che puntellino i colli di bottiglia.
Discorsi tipo "secondo me il collo di bottiglia e' li', allora dobbiamo fare questo e quello", non hanno senso.
be', oddio, lì la situazione è diversa: aldilà di ogni cosa io aspetterei prima di parlar male ad un superiore ^^'
il problema è che a causa di questo fatto ad un superiore non dirò mai quello che penso; però se il superiore mi dice di fare una cosa che ci posso fare? la devo fare ahimè, mi piaccia o no :-\
Il problema non e' quello. Il problema e' nel fatto che in un ambiente professionale non si ottimizza nulla senza una chiara idea dei colli di bottiglia, e se si insiste, e' meglio cercarsi un altro lavoro perche' vuol dire che non si e' tagliati per fare il programmatore per lavoro.
solo perché Microsoft ha il suo bel monopolio e si può cullare sugli allori.
dai su, se st'interfaccia cambia il driver va riscritto, non ci sono santi!!
Non cercare scappatoie, non c'entra nulla il monopolio di Microsoft in una questione puramente tecnica. Il driver model di un sistema operativo puo' cambiare e il kernel e' uno strato che isola le applicazioni da questi particolari interni.
E' la base dei Sistemi di Operativi. Hai fatto il corso?
qua mi si continuano a citare illustrissimi sconosciuti e loro illustrissime frasi insensate :mbe:
Dijkstra non e' un illustre sconosciuto, e' il padre dell'informatica :)
sei o non sei d'accordo che l'"ottimizzazione prematura" non è la causa di tutti i problemi del mondo inerenti la programmazione?
Si', ma questo non e' il significato di quella affermazione. Non fare la traduzione parola per parola per cercare scappatoie, il significato e' chiaro ed evidente: ottimizzare prematuramente e senza dati certi e' un grosso errore.
ma lo sai quello che ci sta in linux tra una system call e un'istruzione di I/O?
Questo pezzo mi era sfuggito.
perchè non ti preoccupi di quello che sai tu invece di occuparti di quello che gli altri sanno sanno?
BountyKiller
13-06-2005, 17:13
allora perché nessuno riscrive IIS e tanti altri programmi Microsoft?
con questa domanda cosa vorresti tacitamente affermare...? scusa sono uscito poco fa dal lavoro non sono lucidissimo....Dijkstra tra le altre cose ha ideato un algoritmo per la ricerca di percorsi minimi su grafi orientati che viene impiegato ancora oggi per la soluzione di problemi di routing
Edsger Dijkstra è uno dei padri dell'informatica... Mai sentito parlare dell'algoritmo di Dijkstra ?
http://www.cs.utexas.edu/users/EWD/
il nostro prof di sistemi ci ha fatto studiare l'algoritmo quando abbiamo parlato di instradamento nelle reti...quell'uomo è un mito. spero l'anno prossimo all'uni di fare un qualche cosa di più approfondito su questo algoritmo :p
perché uno così preparato come mjordan non sa far comunicare un driver con un altro driver che sta ad un livello inferiore in uno stack di drivers?
Perche' io non ho proposto di mettere delle API WIN32 dentro a un kernel? :sofico: Io non ho mica detto che sono migliore di te. Sto solo bramando queste dimostrazioni per imparare qualcosa di nuovo. La mia mente e' avida di sapere :eek:
Perche' non ce lo fai vedere tu? Fino ad adesso hai fatto discorsi su discorsi. Ok. In innumerevoli post ti sto chiedendo di dare una dimostrazione pratica. Altri ti stanno chiedendo di dimostrare quello che tu affermi ci vuole una mezzoretta. Se e' cosi' facile, visto che ci vuole una mezzoretta, perche' non dimostri? Fino ad adesso mi sembra che tu stia attaccando soltanto tutti quelli che hanno risposte lecite, ma contrarie alle tue. Il problema e' che gli altri rispondono con cose che stanno scritte su tutti i libri di "letteratura informatica". Dalla teoria dei sistemi operativi ai principi basi dell'ingegneria del software. Quindi se John Nash stravolse quello che aveva da dire Adam Smith conseguendo un premio Nobel, non vedo perche 71104 non possa stravolgere Edsger Wibe Dijkstra conseguendo un premio Turing. Solo che le cose vanno un tantino dimostrate. E a questo punto non penso di essere l'unico curioso qui' dentro. Perdonami, eh! Che non me ne volessi. Non e' che non credo in quello che proponi. Voglio vedere come realizzare cotanto ben di Dio!
PS: mjordan, ti risponderò col permesso di un moderatore.
Questo e' un forum libero da quello che mi risulta. Non ci vuole il permesso di un moderatore per rispondere. A meno che tu non voglia usare delle offese, puoi rispondere liberissimamente su questo thread. Basta seguire il regolamento che tutti i forum hanno. Quello che ho da dire lo dico liberissimamente su questo forum, uso i messaggi privati per fare domande a delle persone quando non c'e' attinenza con un thread. Non vedo perche' mi devo nascondere. Non vedo perche' debba farlo tu. Sono qui, ti ascolto e, come gli altri, attendo queste benedette dimostrazioni che sembrano latitare. Per quanto riguarda il discorso dell'umilta', io mi lmito a esporre semplicemente cose che ho studiato sui libri. Niente farina del mio sacco! Non sono ancora in grado di scrivere articoli di ricerca, mi spiace. Sto prendendo una laurea in Informatica, non sono ancora pronto per un dottorato di ricerca! :eek:
Mi viene in mente un mio amico di facolta' che durante una lezione del corso di Laboratorio di Informatica Grafica (programmazione OpenGL) mi disse che aveva scritto un motore grafico 3D in OpenGL e che sopra ci stava costruendo un gioco. All'esame scritto prese 9/30 sbagliando la domanda "La rotazione rispetto all'origine e la traslazione di un oggetto sono operazioni commutative? [VERO] [FALSO]". L'unica domanda V/F come regalo del prof. considerata dallo stesso prof. domanda Jolly. :fiufiu:
E' solo un maledetto linux fan :vicini:
Gia'. Sono anche l'unico Linux Fan sul pianeta che non disprezza Windows :sofico:
Mi viene in mente un mio amico di facolta' che durante una lezione del corso di Laboratorio di Informatica Grafica (programmazione OpenGL) mi disse che aveva scritto un motore grafico 3D in OpenGL e che sopra ci stava costruendo un gioco. All'esame scritto prese 9/30 sbagliando la domanda "La rotazione rispetto all'origine e la traslazione di un oggetto sono operazioni commutative? [VERO] [FALSO]". L'unica domanda V/F come regalo del prof. considerata dallo stesso prof. domanda Jolly. :fiufiu:
Io sono stato bocciato due volte all'esame di Informatica Grafica e alla fine l'ho tolto dal piano di studi :p
Io sono stato bocciato due volte all'esame di Informatica Grafica e alla fine l'ho tolto dal piano di studi :p
Ahhhhhhhhhhh che bella notizia che mi hai dato :sofico:
Avevate per caso il Foley/ van Dam / Feiner / Hughes "Computer Graphics: Principles and Practice?
A tutt'oggi ho visto i principles ma ancora ho capito dove sta la practice :sofico:
P.S.: Apro un thread su alcune questioni di "practice", non vorrei andare OT al thread con queste questioni grafiche ;)
Ma senti...quando si dice il destino :)
Ma senti...quando si dice il destino :)
Gia'... Evidentemente era troppo preparato per passare l'esame :D
Scherzi a parte, mi e' capitato molto spesso di sapere TUTTO di una materia e non riuscire a dare l'esame perche' i prof si focalizzano su questioni a dir poco "senza senso e al di fuori della materia"... :muro:
Ma perche' mi viene sempre questo istinto di sapere che ci fanno studiare solo la parte inutile di una materia :cry:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.