google paga per programmare open source

[recoil]

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!!

[VICIUS]

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.

ciao

[mjordan]

Facili fino ad un certo punto. I lavori devono essere accettati dai rispettivi release manager dei vari progetti.

[71104]

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]

Originariamente inviato da 71104

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?

[Fenomeno85]

io ho provato wine e dire che fa schifo è dir poco


~§~ Sempre E Solo Lei ~§~

[RaouL_BennetH]

Originariamente inviato da Fenomeno85

io ho provato wine e dire che fa schifo è dir poco


~§~ Sempre E Solo Lei ~§~

Ma per te il discorso non vale

Tu hai provato un emulatore dentro un emulatore, manco fosse nu gruppo di matrioske

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]

Originariamente inviato da RaouL_BennetH

Ma per te il discorso non vale

Tu hai provato un emulatore dentro un emulatore, manco fosse nu gruppo di matrioske

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?? ... lo avevo provato sotto suse versione installata a parte
~§~ Sempre E Solo Lei ~§~

[Fenomeno85]

ma alla fine wine mica è morto e adesso c'è una versione a pagamento??

~§~ Sempre E Solo Lei ~§~

[RaouL_BennetH]

Originariamente inviato da Fenomeno85

no mai riprovato sotto l'emulazione ma che hai contro il potere di uccidere linux?? ... lo avevo provato sotto suse versione installata a parte
~§~ Sempre E Solo Lei ~§~

ah 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 ?!?

[NA01]

Originariamente inviato da Fenomeno85

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


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

[71104]

Originariamente inviato da VegetaSSJ5

premetto che non ho mai usato wine, cmq perchè dici questo?

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

[VICIUS]

Originariamente inviato da 71104

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.

Originariamente inviato da 71104

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

[71104]

Originariamente inviato da VICIUS

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" ), embe'? lavorassero gli scansafatiche!!
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

[VICIUS]

Originariamente inviato da 71104

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.

Originariamente inviato da 71104

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.

Originariamente inviato da 71104

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 ??

ciao

[mjordan]

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.

[recoil]

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

[71104]

Originariamente inviato da VICIUS

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 ??

cioè, tu conosci il modo di bypassare il sistema di sicurezza di Windows NT?!? ti venero!!!
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.

[71104]

Originariamente inviato da mjordan

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?

[mjordan]

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?

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