NSA - Non Solo Amiga

SOFTWARE => Sistemi Operativi => AROS => Topic aperto da: saimon69 - 17 Dicembre 2014, 19:46:08

Titolo: Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 17 Dicembre 2014, 19:46:08
Come da soggetto.
In un modo o nell'altro sto facendo advocacy ad AROS da almeno sei anni, anche se di recente non ho scritto troppo sul blog, e il problema rimane lo stesso.
Chi conosco che sa programmare (incluso uno dei dev di Powder) considera AROS un giocattolo inutile, datato e che "risolve problemi che non ha nessuno".

Nei miei discorsi - anche nei talk dal vivo e parlando solitamente con la gente quando faccio lo stand nelle fiere tipo SCALE o negli incontri come quello di Robert - solitamente come motivi per collaborare metto:
- la possibilita' di lavorare in con una filosofia diversa e con tool differenti dallo sviluppo moderno;
- un po' di ego visto che siccome non ci sono tanti dev il proprio contributo e' maggiormente riconosciuto;
- un ambiente dove sviluppare retroprogrammi in maniera affidabile;
- la "R di research" in AROS che puo' portare a sperimentare diverse strade o far funzionare cose dove non dovrebbero;
- le bounties;

Mi rendo conto che possono essere motivi non sufficienti, specialmente per i piu giovani che vogliono un ritorno economico dai loro sforzi (ed AROS il rientro economico non sa manco dove sta di casa): avete altri suggerimenti?
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Nonefonow - 17 Dicembre 2014, 20:26:12
Secondo me per mantenere l'interesse in AROS ci vorrebbe uno sforzo coordinato per nuovi programmi / giochi / applicazioni / conduttori / etc.
 
Si potrebbe:
 
1) formulare una specie di lista / elenco delle applicazioni e programmi che necessitano uno sviluppo - basandosi sui bisogni degli utenti.
2) circolare la lista per ottenere la partecipazione dei vari devs basandosi sul loro interesse.  Se sviluppano qualcosa sapendo che qualcuno ha interesse potrebbero essere piu' interessati.
3) mantenere il coordinamento cosi' che i vari progetti continuino a un ritmo predeterminato.
 
I premi sono certamente un'idea per invogliare la gente.  Ma nel mondo di Hollywood conta di piu' il riconoscimento (credits) e la popolarita' per solleticare l'ego dei programmatori.
 
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 17 Dicembre 2014, 21:07:07
@nonefonow
[OT]

Oddio, se ci limitiamo strettamente a Hollywood e all'ambiente della cosi' chiamata "tinseltown" ho capito che qua i "credits" li vogliono di entrambi i tipi: Fama e Dindi :/

Ah, e Gnocca come effetto della combinazione dei due ^^

[/OT]
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Allanon - 17 Dicembre 2014, 21:16:59
...Gnocca...
Questa potrebbe smuovere molti dev secondo me   8)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 17 Dicembre 2014, 21:18:15
...Gnocca...
Questa potrebbe smuovere molti dev secondo me   8)

Noi AROSiani ciabbiamo la kitty come Mascotte, che e' una bella micia (in inglese pussy, nomignolo per la succitata gnocca), ma me sa che non basta :P
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 17 Dicembre 2014, 21:26:09
E, riprendendo, rispondo ancora a nonefonow:

l'idea della lista e' in giro da un pezzetto ed e' inclusa nel concetto di bounties; problema e' che i programmi che servono o usano dei tool non portati o hanno modalita' interne di operazione piu' legate ai sistemi moderni (vedi fork e pthreads); inoltre in questo momento programmare su Amiga ed AROS e' al livello dell'arte dei liutai: usa metodi e filosofie ritenute obsolete e scarsa documentazione (in miglioramento anche grazie a fonti esterna ma sempre un problema).

Personalmente penso che trovare una certa nicchia oltre al retrocomputing dove l'uso di AROS risulti vantaggioso aiuti a farlo notare; in passato ricordo il padre di un mio amico che usa HAM radio e usava amiga per maneggiare i sistemi: in tempi meno avanzati per sta gente un port del software sotto AROS sarebbe stato deternminante, ma dopo anni di dominio win e linux non saprei...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 17 Dicembre 2014, 22:05:46
Per quanto mi riguarda, è la R di AROS che mi attira, oltre ovviamente al fatto che partiamo da una base "Amiga o.s.". La componente nerd/geek/smanettona è, ovviamente, implicita.

Il problema, manco a dirlo, è il tempo, anche se stamattina ho finalmente chiuso un progetto molto importante (ho effettuato una submission a una delle commissioni aziendali per la valutazione di un possibile brevetto su un'idea che ho sviluppato in questi mesi). Domani c'è l'ultima lezione del corso di tedesco. Un altro progetto personale conto di chiuderlo spero entro quest'anno. Così finalmente libererei un po' di tempo libero, ma soprattutto farei un favore a per me stesso, perché sono abbastanza stressato da tutte le cose che ho da fare, e ho BISOGNO di tornare a respirare e dormire un po' (troppe ore strappate al sonno negli ultimi tempi).

A questo punto ci sarebbe spazio per fare qualcosa per AROS. Ho diverse idee in merito, e alcune le ho già espresse anche di recente. Come diceva Paolo qualche ora fa su aros-exec, il problema principale per un sistema amatoriale come questo è il software (con l'hardware non siamo certo messi male): senza questo non si può attirare gente.

Per cui la mia idea è che probabilmente è meglio, come prima cosa, investire un po' di tempo cercando di portare una delle ultime versioni di Python su AROS. Precondizione: devo avere un ambiente di sviluppo che giri su Windows. Di lavorare su Linux, anche sfruttando eventualmente una virtual machine, non se ne parla, perché dopo questo periodo che mi sta succhiando energie a josa, ho voglia / bisogno di fare qualcosa per puro divertimento. Dunque proverò con AROS hosted su Windows, e a crearmi un ambiente con MingW per effettuare cross compilazione.

Se tutto riesce, come spero, ho già in mente un altro progetto, ma è qualcosa di particolarmente complicato. Però qui rientra la variabile ueber-smanettamento che mi fa salire l'adrenalina soltanto al pensiero di quello che c'è da fare. ;D

EDIT. Dimenticavo: se AROS / Icaros migliorerà su certi aspetti, ho qualche idea per cercare di dargli maggior spazio in ambiti completamente diversi. Ma ne riparliamo quando arriverà il momento.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 18 Dicembre 2014, 00:03:34
Se gli dici che se sviluppano su AROS fanno girare i cocomeri a Trevor DICKinson? ;D

Fuori dal mondo amighista Manco lo sanno chi e': a veder le foto parrebbe un malato di bipolare che quando e' senza medicine si veste da pagliaccio a quadretti bianchi e rossi :/
(https://lh4.googleusercontent.com/-Rj3EebLh6X8/VEwgEcLavOI/AAAAAAAAJCk/IOZ96FOBuGw/s640/blogger-image--1725289017.jpg)

E cmq, bando agli ad hominem, poraccio lui lo rispetto: ci crede sul serio e ci ha investito (e perso) fior di dindi; e' il resto della cricca osquattrista (Hermans, AmigaKit, ssolie, i gemelloni crudebusters, damato, ecc.) , la loro arroganza e il loro sentirsi superiori al resto degli amighist e comunita' che non sopporto ...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Amig4be - 18 Dicembre 2014, 11:02:31
considera AROS un giocattolo inutile, datato e che "risolve problemi che non ha nessuno".


e ha assolutamente ragione... quindi per interessarsi al giocattolo bisogna per prima cosa essere interessati al gioco.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: lucommodore - 18 Dicembre 2014, 14:27:08
Compari ma, un po' per tutte questo genere di "cose", per generare interesse si pubblicizza.
Nel caso specifico, ciò che funziona bene è fare comunità intorno al prodotto, esportare il fatto che i membri della comunità si divertono un mondo con esso e, quindi, pubblicizzare la comunità...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 18 Dicembre 2014, 18:28:23
@lucommodore

Facciamo un crowdsourcing per manifestoni "Non pettiniamo piu' le bambole" da mettere sulla tangenziale? :P
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: lucommodore - 18 Dicembre 2014, 18:44:47
@saimon69
Bisognerebbe pubblicizzare verso un target di riferimento, un cartellone non servirebbe a niente.
Su C=FG qualcosa lo facciamo e son convinto che qualche utente in più l'ha portato, già riuscire ad inserire un articolo su Icaros in ogni numero sarebbe buona cosa ma siamo limitati al prospect italiano.
Forse si potrebbe chiedere ad altre riviste/fanzine. Ho qualche dubbio sui forum, son passato oggi da quello di TGM e c'è talmente poca gente che sembra quasi un cimitero... :(
AROS a livello commerciale è un po' un cane che si morde la coda: essendoci pochi utenti, difficilmente si muovono i coders che, l'abbiamo toccato con mano in altri thread, se non c'è della "fresca" da tirarci su, non si muovono mai; solo che, per portare utenza, occorre una base sw in qualche modo gratuita...
Secondo me la cosa potrebbe cambiare in senso positivo se girasse su piattaforme diffuse ed economiche prive di sw per l'uomo medio...
AROS ci gira su Raspberry Pi ad esempio? Ecco lì si potrebbe imho impostare qualcosa di potenzialmente promettente, spingendo anche solo sul vecchio sw per C=Amiga...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 18 Dicembre 2014, 20:27:51
@lucommodore

l'anno scorso Kalamatee lavorava a portare AROS nativamente su Raspberry PI; purtroppo diversi fattori tra problemi con lo stack USB, disoccupazione, famiglia (e' padre di tre bambine) e anche scarse donazioni alla bounty gli han fatto metter da parte quel target. Se ciai voglia di fare una donatina o di spronare altri a farlo magari poi finisce il lavoro...

...visto che proprio la Raspberry Pi ed altre board similari parrebbero un buon posto per AROS visto che in confronto a una distro linux usa meno risorse :)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: lucommodore - 18 Dicembre 2014, 21:04:24
@lucommodore

l'anno scorso Kalamatee lavorava a portare AROS nativamente su Raspberry PI; purtroppo diversi fattori tra problemi con lo stack USB, disoccupazione, famiglia (e' padre di tre bambine) e anche scarse donazioni alla bounty gli han fatto metter da parte quel target. Se ciai voglia di fare una donatina o di spronare altri a farlo magari poi finisce il lavoro...

Beh compare, più di tanto non si può fare ma, da utente iscritto a NSA, potresti portare alla redazione di C=FG la proposta di pubblicizzare qualche bounty.  ;)
Per me si potrebbe anche esagerare con queste cose, per come sono io si potrebbero dedicare anche diverse pagine su C=FG che pubblicizzano bounty e, togliendo pagine ai redazionali si potrebbe anche pubblicare C=FG con una cadenza un po' più "umana"...

Queste robe non le usate mai ma da qua a C=FG si può chiedere di tutto: http://www.commodorefangazette.com/scrivi

In fondo sono un sacco di lettori... magari qualcuno poi riporta la cosa anche all'estero... magari da cosa nasce cosa... ;D

O magari una ceppa di fungia ma tentar non nuoce mai. ;)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 19 Dicembre 2014, 00:04:55

Queste robe non le usate mai ma da qua a C=FG si può chiedere di tutto: http://www.commodorefangazette.com/scrivi

In fondo sono un sacco di lettori... magari qualcuno poi riporta la cosa anche all'estero... magari da cosa nasce cosa... ;D

O magari una ceppa di fungia ma tentar non nuoce mai. ;)

Visto che ho quasi finito con i diari di Powder su AD potrei anche :)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: xteamsoftware - 19 Dicembre 2014, 16:33:40
Bisognerebbe fare un mercato in modo che chi sviluppa abbia possibilità di "ricavarci" qualcosa.
Noi abbiamo firmato un accordo con la Forgotten Empires per sviluppare un nuovo Age of Empires, avevamo chiesto di fare qualcosa per i mercati minori ma dal loro business plane non ha senso provarci.

E' un cane che si magia la coda
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: lucommodore - 19 Dicembre 2014, 17:21:59
Bisognerebbe fare un mercato in modo che chi sviluppa abbia possibilità di "ricavarci" qualcosa.
Noi abbiamo firmato un accordo con la Forgotten Empires per sviluppare un nuovo Age of Empires, avevamo chiesto di fare qualcosa per i mercati minori ma dal loro business plane non ha senso provarci.

E' un cane che si magia la coda
Per spingere i primi coder a combinarci qualcosa basterebbe un'utenza più cospicua. Se diventasse l'OS per il Raspberry Pi, l'utenza arriverebbe in automatico e, di conseguenza anche qualche coder... imho.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: xteamsoftware - 19 Dicembre 2014, 19:10:06
Bisognerebbe fare un mercato in modo che chi sviluppa abbia possibilità di "ricavarci" qualcosa.
Noi abbiamo firmato un accordo con la Forgotten Empires per sviluppare un nuovo Age of Empires, avevamo chiesto di fare qualcosa per i mercati minori ma dal loro business plane non ha senso provarci.

E' un cane che si magia la coda
Per spingere i primi coder a combinarci qualcosa basterebbe un'utenza più cospicua. Se diventasse l'OS per il Raspberry Pi, l'utenza arriverebbe in automatico e, di conseguenza anche qualche coder... imho.

E' il concetto mio di mercato: più utenti.

Bisognerebbe coinvolgere qualche università, eventualmente qualche progetto open source "grosso", qualche porting su macchine particolari ( penso a qualche console ). Se i numeri sono piccoli è difficile che si muovano i team, al più qualche appassionato
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: xteamsoftware - 19 Dicembre 2014, 23:52:32
quali console con AROS ?

PSVita, le console android ( OUYA, M.O.J.O.,JXD, ..... ), quelle linux open ( Open Pandora, GP2X Caanoo, GCW Zero,.... ).
Ovviamente non dico che sia facile, anche riuscire a fare girare AROS hosted su android sarebbe un bel colpo.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 20 Dicembre 2014, 01:06:06
quali console con AROS ?

PSVita, le console android ( OUYA, M.O.J.O.,JXD, ..... ), quelle linux open ( Open Pandora, GP2X Caanoo, GCW Zero,.... ).
Ovviamente non dico che sia facile, anche riuscire a fare girare AROS hosted su android sarebbe un bel colpo.

AROS hosted on Android cello... Aros/Platforms/Installing on Android (wikibooks) (http://en.wikibooks.org/wiki/Aros/Platforms/Installing_on_Android)
e c'e' anche un video: Aros running on Android tablet Onda vx610w (https://www.youtube.com/watch?v=QhiU_GqTxhc)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 20 Dicembre 2014, 06:47:40
Il problema delle console portatili è che generalmente non puoi attaccarci mouse e tastiera, che sono indispensabili per usare AROS.

Ho una splendida PSP versione 2000 che ho usato tanto tempo come retrogaming station portatile, ma senza tastiera è davvero complicato usare certi computer.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: xteamsoftware - 20 Dicembre 2014, 09:05:21

Visto che hosted su Android gira ( io ho fatto riferimetno al sito ufficiale e non c'era nulla ) perchè non portatlo su OUYA.
Tastiera e mouse ci sarebbero

http://ouyabrew.com/wireless-keyboard-and-mouse-all-in-one/

Io parlo non di utilità di AROS su una console portatile,  ma di far parlare del progetto
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 20 Dicembre 2014, 09:11:27
Preferirei una normalissima tastiera, comunque è un notevole passo avanti.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 20 Dicembre 2014, 10:27:48
Citazione da: legacy
non capisco che senso ha, sopratutto sulle console: se deve essere un gameOS deve avere un profilo ben diverso dal g.p.OS
Beh, il s.o. di Amiga era/è estremamente leggero, oltre al fatto che è piccolissimo. Anche per questo rimane molto interessante.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 03 Gennaio 2015, 00:15:59
@cdimauro

E' un qualcosa cui di solito punto quando spiego alla gente i vantaggi; se non hanno grandi richieste di sicurezza e spazio ridotto penso AROS sia ideale.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 03 Gennaio 2015, 07:56:37
@cdimauro

E' un qualcosa cui di solito punto quando spiego alla gente i vantaggi; se non hanno grandi richieste di sicurezza e spazio ridotto penso AROS sia ideale.
Credo che in futuro si potrà far evolvere "con tutti i crismi", rimanendo sempre abbastanza leggero e ingombrante. Ma al momento l'obiettivo primario è raggiungere la famigerata 1.0.

La R di AROS deve ancora "dare". E molto. IMO.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 03 Gennaio 2015, 09:19:35
Citazione da: legacy
a quel punto c'e' pure Haiku :D
Ma anche no: in primis basta coi s.o. POSIX, e in ogni caso non penso che sia snello come AROS. 8)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Allanon - 03 Gennaio 2015, 11:09:41
è tanto che non ci butto un occhio su Haiku... chissà com'è messo...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 03 Gennaio 2015, 12:41:01
BeOS per me rimane una bella, ma chiusa parentesi. Poi col poco tempo che ho devo fare di necessità virtù, per cui quando posso lo impiego esclusivamente su AROS.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 04 Gennaio 2015, 09:50:57
dettagli  :D
No. Le differenze architetturali sono profonde.
Citazione
ora ora mi ingolosisce che Haiku ha un filesystem molto + interessante
Lo puoi implementare anche in altri s.o.. ;)

Cosa ha di interessante AROS? Sulla pagina di wikipedia non ho trovato nulla sull'architettura del kernel, etc.. ho letto solo che offre le stesse API di AmigaOS (quindi comunque potrebbe essere implementato diversamente).
Sì, l'implementazione è diversa, perché è stato realizzato da zero, partendo dalla documentazione rilasciata da Commodore. Potremmo parlare di approccio "clean-room".
Citazione
Non è una provocazione la domanda, sono totalmente asciutto di questi Amiga-like OS
Non so a che tipo di informazioni sei interessato. Ti riporto un po' di link dal wiki di AROS:
http://en.wikibooks.org/wiki/Aros/Developer/Docs
http://en.wikibooks.org/wiki/Aros#Developer_-_Developing_for_AROS.2C_and_developing_AROS
http://en.wikibooks.org/wiki/Aros/Developer/Docs/Resources/Kernel
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 04 Gennaio 2015, 17:43:08
No. Le differenze architetturali sono profonde.

dicevo che posix non piaccia sono dettagli
Non per chi deve utilizzarlo per sviluppare software.
Citazione
perche' di fatto tiene su mezzo mondo di applicazioni
Purtroppo.
Citazione
chi ha messo su BeOS e poi Haiku queste cose le ha ben considerate
Si sono accodati alla massa...
Citazione
Citazione
Lo puoi implementare anche in altri s.o.. ;)

ma ti sei mai chiesto perche' sono sono anni che su linux BeFS e' in RO  :o :o :o
e nessun altro OS l'ha mai implementato ?
Perché è un filesystem particolarmente complicato (o ricco di feature), e richiede parecchio tempo per essere implementato correttamente. Un filesystem non è un software come un altro: è codice mission critical, e serve parecchio per la sua scrittura e, soprattutto, testing.

BeFS non è il solo s.o. che, nonostante anni di lavoro, non risulta ancora "perfettamente" implementato. Su Linux sono diversi, da ReiserFS a BTRFS (sì, è quasi stabile, ma non ancora "gold"), per finire al mito di ZFS...

che poi, per praticità, per entrambi si arriva a questa (http://www.osnews.com/comments/27907) soluzione ibrida.
Che aborrisco. Anche ARIX funziona in maniera similare.

A me BeOS/Haiku piace tantissimo, riguardo POSIX finché è solo un layer di compatibilità e non il layer principale, non ci vedo nulla di male.
Come libreria a parte, che "wrappa" le API native, non c'è problema alcuno.
Citazione
E poi non avere un layer di compatibilità POSIX implica (aimhé) che una buona parte delle applicazioni è tagliata fuori, se vuoi diffondere l'uso dell'OS è da fare
E' un problema comune, visto che nemmeno Windows ha un layer POSIX, nemmeno come libreria esterna. D'altra parte, anche con tutta la buona volontà che ci potrebbe essere, essere compatibili POSIX non è sempre possibile, a seconda delle caratteristiche del s.o. principale e delle API che offre. Ad esempio né Windows né il s.o. di Amiga hanno / supportano la famigerata fork()...

POSIX, a mio avviso, è un male (assoluto).
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 04 Gennaio 2015, 18:32:11
E' un problema comune, visto che nemmeno Windows ha un layer POSIX, nemmeno come libreria esterna.

Windows è parecchio diffuso però, non hanno bisogno di un layer di compatibilità POSIX :P
Meno male. 8)
Citazione
In realtà c'è Interix (http://en.wikipedia.org/wiki/Interix), ma non credo sia molto utilizzato
E' molto valido, ma è disponibile soltanto con le versioni professionali di Windows. Per cui non puoi tenerne conto / utilizzarle quando devi realizzare il porting di un'applicazione da un sistema POSIX.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 05 Gennaio 2015, 06:53:34
@cdimauro

il layer di compatibilita' POSIX, ancora un altra situazione "uovo o gallina" che si presenta per il port di software: ricordo come fosse stato parzialmente (e malamente) risolto sotto Amiga con la ixemul.library e tutto il software del GeekGadgets CD; se non fosse un passaggio quasi forzato per avere piu' programmi ne farei volentieri a meno, e si e' gia' discusso sia su aros-exec che nella mailing list su ncome espandere il sistema di librerie si da permettere il port di software che usa shared objects ma in un modo piu' compatibile con il modus amighista, e parmi di ricordare Staf opporsi a questo...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Gennaio 2015, 08:07:05
Staf non lo conosco, ma personalmente sono contrario all'introduzione degli shared object quando dal day one il s.o. di Amiga si fonda sulle librerie. In un articolo di tempo fa avevo suggerito come estendere le librerie per consentire di avere il segmento dati "per task" (dunque privato), ma oltre questa soluzione non ha senso procedere: si snaturerebbe tutto, appiattendosi sulle posizioni di altri s.o..

A me piace ancora il s.o. di Amiga perché ha portato una ventata di novità nell'asfittico panorama (tutti a fossilizzarsi su Unix/POSIX). Mi piace AROS perché si fonda rigorosamente su di esso, ma consente di sperimentare e ricercare (grazie anche al fatto che il nucleo è piccolo, semplice, e leggero).

Nel momento in cui si uniformerà agli altri, perderà il suo fascino e per quanto mi riguarda finirà nel dimenticatoio. Rimarrà solo WinUAE a ricordarmi i vecchi tempi.

Anche per questo non amo le versioni hosted o virtualizzate, tranne per lo sviluppo / smanettamento.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Allanon - 05 Gennaio 2015, 18:06:49
@dsar, ti ringrazio per avermi riportato alla mente questo interessantissimo os con cui ho avuto qualche sporadico incontro ma mai approfondito come si deve, adesso mi vado a cercare una distribuzione con cui smanettare  ;D
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Gennaio 2015, 19:54:07
Fammi capire: in /dev/vdu_ctrl mandi quei comandi come line, square, ecc., e il driver che gestisce /dev/vdu_ctrl poi li decodifica, controlla se i parametri sono corretti, e procede con l'esecuzione del comando? Dunque abbiamo:
- l'applicazione che deve CODIFICARE il comando e i relativi parametri che devono essere eseguiti;
- l'applicazione che deve spedire il buffer a /dev/vdu_ctrl;
- il device che deve DECOFICARLI e CONTROLLARE che non gli hai mandato ciarpame nello stream;
- il device, alla fine, esegue ciò che gli hai richiesto.

Vedi perché Unix è una cacata pazzesca? A forza di estendere il concetto di "file per modellare / controllare tutto", si creano mostruosità come queste.

Sul s.o. di Amiga, invece:
- l'applicazione passa i parametri del comando/API sui registri;
- invoca l'API dell'apposita libreria;
- la libreria, AL MASSIMO, valida il valore dei parametri, ma poi passa immediatamente a eseguire il comando/API.

Per quanto mi riguarda: http://web.mit.edu/~simsong/www/ugh.pdf

@dsar: come sai, da pascaliano mi piacciono i linguaggi di Wirth, e ai tempi dell'Amiga ero rimasto affascinato da Modula-2 prima e Oberon poi (anche se alcune cose mi hanno fatto un po' storcere il naso). Ma non avevo mai sentito parlare del s.o. Oberon; alcune cose, come quella dei file che hai spiegato, sembrano molto interessanti.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Gennaio 2015, 20:35:41
Rimane una "trovata" assolutamente inefficiente nell'uso comune. Un po' come quella cacata galattica di X11, che uccide l'accelerazione grafica sui sistemi Unix, se non trovi il modo di aggirarla.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Gennaio 2015, 20:49:05
Nel primo caso (IRIX) un sistema a librerie sarebbe stato di gran lunga più efficiente.

Nel secondo caso (X11), è l'approccio a essere totalmente sbagliato. Localmente la grafica deve essere gestita al massimo dell'efficienza. SE (e solo se) ti serve lavorare con desktop remoto, metti in piedi un proxy che smista le chiamate alle primitive grafiche dove vuoi.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 05 Gennaio 2015, 21:10:47
Si son creati due sotto-discorsi quindi rispondo a punti

1) In Linux, il driver ufficiale NVIDIA è composto da una parte user-mode e da una parte kernel-mode, le quali parlano tra di loro attraverso il device /dev/nvidia0; le prestazioni grafiche sotto Linux son state più volte misurate essere pari se non superiori (comunque di pochi %) a quelle della stessa versione su Windows (i due driver condividono la quasi totalità di codice).
Quindi un sistema del genere non impone "meno efficienza" (sarà anche che probabilmente la generazione dei command buffer avviene in user-mode e la parte kernel si preoccupa solo di fare DMA verso la GPU, quindi già i dati sono in forma di "bufferone di byte").

2) X11 è una cacata, e il fatto che sia usato in sistemi obsoleti o dal lunghissimo supporto non lo giustifica; come architettura andava bene negli anni '80 ma già toccando il millennio era inutilmente inefficiente e pesante. Al giorno d'oggi nessun desktop environment/window system/toolkit usa le primitive di disegno di X ma spediscono direttamente buffer di immagini (inefficientemente, perchè non esegue compressione né manda solo le zone dirty), quindi non regge neanche la scusa che è "network transparent".
L'unico motivo per tenere in vita X è solo quello di usarci le applicazioni troppo vecchie per essere aggiornate, nient'altro.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Gennaio 2015, 21:13:29
Piccolo appunto sull'1): senza passare da /dev/nvidia0, ma con un sistema a librerie, le prestazioni sarebbero migliori e il consumo di memoria inferiore.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 06 Gennaio 2015, 01:43:30
Piccolo appunto sull'1): senza passare da /dev/nvidia0, ma con un sistema a librerie, le prestazioni sarebbero migliori e il consumo di memoria inferiore.

[citation needed]; finchè non si prova non possiamo saperlo.

Anzi, sostengo che, usando un sistema a chiamate a funzione, le prestazioni peggiorerebbero. Ecco su cosa mi baso per dirlo:
Un sistema formato da chiamate a funzione dirette a una libreria di sistema può venire realizzato in due modi:
Nel primo caso, le prestazioni crollerebbero drammaticamente, perchè già adesso il tempo di esecuzione di ogni funzione dell'API grafica è critico; se poi dobbiamo anche introdurre una chiamata a una libreria (che per ragioni di sicurezza e tutto non sarà mappata nello spazio dell'applicazione, e se lo fosse, torneremo nel sistema che già è in uso quindi non cambierebbe nulla), la pesantezza aumenterebbe.
Nel secondo caso, le prestazioni rimarrebbero sempre le stesse, in quanto alla fine non abbiamo fatto altro che rinominare le funzioni read() e write().
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 06 Gennaio 2015, 09:53:44
Piccolo appunto sull'1): senza passare da /dev/nvidia0, ma con un sistema a librerie, le prestazioni sarebbero migliori e il consumo di memoria inferiore.

[citation needed]; finchè non si prova non possiamo saperlo.
Proviamolo. 8)
Citazione
Anzi, sostengo che, usando un sistema a chiamate a funzione, le prestazioni peggiorerebbero. Ecco su cosa mi baso per dirlo:

  • La gestione dell'I/O su file di Linux è estremamente ottimizzata (ci mancherebbe altro), e sopratutto anche per applicazioni in-memory (le pipe non sono altro che file descriptor)
Il fatto che sia ottimizzata su Linux non implica che sia migliore di altri metodi.
Citazione
  • Son sicuro al 99% che NVIDIA fa tutto il lavoro in user-mode e manda all driver kernel solo i comandi già elaborati e formattati per essere letti dalla GPU (praticamente lato kernel basta avviare e gestire le operazioni di DMA);
La stessa identica cosa si può fare anche con una libreria.
Citazione
son ancora più sicuro basandomi sulla recente presentazione (http://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead) dove viene discussa una nuova estensione che hanno introdotto in OpenGL per permettere alle applicazioni di generare "manualmente" le command-list (e ridurre al minimo le draw-call che un'applicazione deve fare ogni frame). Con un'architettura come quella che ho descritto, questa aggiunta è molto più semplice e immediata.[/li][/list]
Perché non si potrebbe fare altrettanto con una libreria?
Citazione
Un sistema formato da chiamate a funzione dirette a una libreria di sistema può venire realizzato in due modi:
  • La libreria di sistema è praticamente la libreria grafica (OpenGL diciamo), quindi ogni chiamata a funzione dell'API nell'applicazione deve essere inviata alla libreria di sistema in modo che la gestisca;
  • La libreria di sistema si riduce solamente a send_buffer() e receive_buffer() per inviare i comandi direttamente alla GPU, e il driver rimane implementato come uno shared object che viene caricato dall'applicazione.
Nel primo caso, le prestazioni crollerebbero drammaticamente, perchè già adesso il tempo di esecuzione di ogni funzione dell'API grafica è critico; se poi dobbiamo anche introdurre una chiamata a una libreria (che per ragioni di sicurezza e tutto non sarà mappata nello spazio dell'applicazione, e se lo fosse, torneremo nel sistema che già è in uso quindi non cambierebbe nulla), la pesantezza aumenterebbe.
Non ho parlato di libreria di sistema, ma di libreria. Dunque perfettamente gestibile in user-space, al costo di:
- una LOAD LibraryBase (solo la prima volta nel caso di chiamate consecutive alla libreria) nel registro usato per memorizzarla;
- una CALL a un certo offset dal registro per eseguire il codice.
Questo in un s.o. Amiga/like, perché c'è la necessità di passare / usare la LibraryBase.

In altri s.o. è possibile, invece, "risolvere" al caricamento della libreria gli indirizzi delle funzioni che sono necessarie all'applicazione, per cui chiamare un'API significa soltanto:
- una CALL PuntatoreAllaAPI (questo su x86/x64; su processori RISC in genere serve una LOAD e una CALL).

Dunque richiamare l'API di una libreria è un'operazione estremamente veloce, di gran lunga più veloce rispetto al meccanismo di:
- codifica dell'operazione da eseguire in un buffer (e quindi ti serve anche memoria allo scopo);
- invocazione della syscall fwrite (dunque passaggio da user a kernel mode: context switch!);
- in base al file handle, il kernel deve capire a quale device deve spedire i parametri della fwrite;
- chiamata al fwrite del device;
- nel caso del device nvidia0, questo deve analizzare il buffer e capire cosa ha scritto l'applicazione. Dunque parsing di uno stream dati -> recupero del codice/opcode del comando invocato & relativi parametri;
- a questo punto viene "invocato" il comando (codice comune all'API della libreria: stesse cose da fare);
- il device restituisce il controllo al kernel;
- il kernel restituisce il controllo all'applicazione (passaggio da kernel a user mode: un altro context switch).

Per quanto possa essere ottimizzato in Linux, tutto ciò rimane decisamente più pesante e complicato da gestire. Una chiamata a libreria è immensamente più semplice.
Citazione
Nel secondo caso, le prestazioni rimarrebbero sempre le stesse, in quanto alla fine non abbiamo fatto altro che rinominare le funzioni read() e write().
Ma anche no: vedi sopra.

E non abbiamo nemmeno tenuto conto del fatto che per utilizzare /dev/nvidia0, devi aprire un file, e dunque devi eseguire una syscall che il kernel mapperà nell'apposito device, una volta che l'avrà trovato durante il parsing del path passato. Poi servirà allocare un file handle appositamente (dunque allocazione di memoria in kernel space per la struttura interna utilizzata allo scopo).

Non è una dimostrazione formale, ma mio avviso risulta piuttosto chiaro che l'approccio a libreria sia intrinsecamente più efficiente di quello tramite utilizzo di un file "speciale".
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 06 Gennaio 2015, 14:57:33
Il fatto che X11 giri, pure bene in alcuni sistemi, non toglie nulla al fatto che sia una soluzione insensata e inefficiente.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 06 Gennaio 2015, 18:30:52
@cdimauro

E' una risposta WorksForMe[tm] :P
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 06 Gennaio 2015, 18:37:38
Lo so, e non ho nulla da dire da questo punto vista. Ma da sviluppatore con una certa esperienza mi si torcono le budella quando vedo certe porcate... :-\
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 06 Gennaio 2015, 19:00:41
Devo andare a vedermi Capitan Harlock con la famiglia, quindi un appunto solo su questo:
(soprattutto quello implementato ad uso e consumo linux/BSD, sopratutto la super cazzata di aver usato una macchina virtuale x86 per inizializzare le schede video, questa cosa e' una cazzata galattica che non funziona quasi mai su nessuna macchina non x86, quindi non ha 2 volte motivo di esistere)
Purtroppo questo "hack" è necessario, perché non c'è altro modo per inizializzare una scheda grafica VESA e da usare poi col framebuffer.

Ed è una cosa sulla quale mi sto cimentando di recente. Vediamo se ne uscirà fuori qualcosa di utile per AROS.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Allanon - 06 Gennaio 2015, 20:43:06
@cdimauro
Piccola parentesi OT: io Capitan Harlock l'ho visto un paio di giorni fa, se vuoi in un thread apposito ne parliamo :)
Buona visione!
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 06 Gennaio 2015, 22:13:40
Per me va bene. :)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 07 Gennaio 2015, 00:51:38
Proviamolo. 8)
Se riesci a procurarti i sorgenti del driver NVIDIA, ci darei volentieri un'occhiata! :P
(il mio "proviamo" era più da leggere come "tentiamo in modo pratico", una mezza allegoria per dire che, senza due implementazioni che sfruttano i due sistemi e che possiamo misurare, solo in via teorica è difficile concludere)

Il fatto che sia ottimizzata su Linux non implica che sia migliore di altri metodi.
Era per dire che, nonostante sia una chiamata a un sottosistema generico come il filesystem, l'esecuzione per questo caso particolare è comunque molto veloce.

La stessa identica cosa si può fare anche con una libreria.
Perché non si potrebbe fare altrettanto con una libreria?
Ovvio che si può fare; il dibattito non è cosa si può/non si può fare, ma quanto veloce è, e la mia tesi è che non c'è una così grande differenza in questo caso.

Non ho parlato di libreria di sistema, ma di libreria. Dunque perfettamente gestibile in user-space, al costo di:
- una LOAD LibraryBase (solo la prima volta nel caso di chiamate consecutive alla libreria) nel registro usato per memorizzarla;
- una CALL a un certo offset dal registro per eseguire il codice.
Questo in un s.o. Amiga/like, perché c'è la necessità di passare / usare la LibraryBase.

In altri s.o. è possibile, invece, "risolvere" al caricamento della libreria gli indirizzi delle funzioni che sono necessarie all'applicazione, per cui chiamare un'API significa soltanto:
- una CALL PuntatoreAllaAPI (questo su x86/x64; su processori RISC in genere serve una LOAD e una CALL).

Dunque richiamare l'API di una libreria è un'operazione estremamente veloce, di gran lunga più veloce rispetto al meccanismo di:
- codifica dell'operazione da eseguire in un buffer (e quindi ti serve anche memoria allo scopo);
- invocazione della syscall fwrite (dunque passaggio da user a kernel mode: context switch!);
- in base al file handle, il kernel deve capire a quale device deve spedire i parametri della fwrite;
- chiamata al fwrite del device;
- nel caso del device nvidia0, questo deve analizzare il buffer e capire cosa ha scritto l'applicazione. Dunque parsing di uno stream dati -> recupero del codice/opcode del comando invocato & relativi parametri;
- a questo punto viene "invocato" il comando (codice comune all'API della libreria: stesse cose da fare);
- il device restituisce il controllo al kernel;
- il kernel restituisce il controllo all'applicazione (passaggio da kernel a user mode: un altro context switch).

Per quanto possa essere ottimizzato in Linux, tutto ciò rimane decisamente più pesante e complicato da gestire. Una chiamata a libreria è immensamente più semplice.

Non hai capito; mi sa che stiamo parlando di cose un po' diverse, perciò mi spiego meglio:
prima di tutto, io sto parlando di questo particolare caso del driver e GPU NVIDIA, e non altre librerie di alto livello (come potrebbe essere la libc ad esempio, o altre librerie di disegno più "interattive" come SDL).

Secondo, un'applicazione OpenGL che usa il driver NVIDIA su Linux funziona circa così:
1) Il driver NVIDIA è composto da due parti: una che lavora kernel-mode (e che  è responsabile della creazione del device /dev/nvidia0), e una parte user-mode (che parla con l'applicazione per esporre tutte le funzioni dell'API).
La parte user non lavora in un suo processo, e quindi sospetto che sia tutto dentro la libreria libGL.so (che, come si capisce dal nome, espone OpenGL), o al massimo ad un'altra libreria che viene caricata da libGL stessa.

2) Le GPU moderne non lavorano con la tecnica di una volta imposta_registri - esegui - imposta_registri - esegui etc, perchè sarebbe una lentezza esorbitante; quello che succede è che lato CPU viene creata una lista di comandi, sotto forma di un bufferone di strutture, che viene inviato in blocco alla GPU tramite DMA; la GPU al suo interno possiede un processore di controllo che interpreta i dati e fa il dispatch dei vari comandi ai vari core di esecuzione parallela.

3) Detto questo, lato CPU abbiamo "solo" il compito di tradurre le chiamate che l'applicazione fa a OpenGL nell'apposito bufferone di comandi; da quanto posso osservare dall'esterno, credo che questa operazione venga fatta solo dal sistema user-mode, quindi da libGL.so diciamo.
Quindi, attraverso /dev/nvidia0 (che ora che ci penso probabilmente è aperto in mmap, quindi non ci sono neanche copie dovute a read() e write()) ci passano solo dati che sono già organizzati per essere inviati alla GPU (e al suo controller interno); quello che la parte kernel-mode deve solo fare è fare un po' di serializzazione in base al PID (nel caso ci siano più applicazioni che usano libGL), e gestire le operazioni di DMA.

Detto questo, un sistema del genere non risente dello "strano" modo di mappare i dispositivi su file tipico degli Unix.
Se dovessimo implementare un sistema del genere tramite una "libreria", si potrebbe fare in due modi diversi (che sono i due punti che avevo elencato sopra):

Fine. Ricapitolando: in questo particolare caso, il sistema e le condizioni sono tali da non prendere un colpo dal particolare sistema di comunicazione via file descriptor.

Citazione
Non è una dimostrazione formale, ma mio avviso risulta piuttosto chiaro che l'approccio a libreria sia intrinsecamente più efficiente di quello tramite utilizzo di un file "speciale".

Questo è ovvio ("ovvio" non per sminuire quello che hai detto, ma che si spera sia evidente a chiunque nel settore), se parliamo di una libreria generica; praticamente si avrebbe la pesantezza di un sistema di message passing unito alla pesantezza delle operazioni del filesystem.
In questi casi particolari, invece, dove la destinazione di queste informazioni è già un dispositivo hardware che lavora più o meno a stream di byte, la differenza è molto meno sentita, se non annullata.
Riprendiamo l'esempio di legacy: ovviamente quel sistemino lì è molto pesante, perchè l'applicazione, il driver e la CPU devono far lavoro di codifica/decodifica dei dati solo e unicamente per conformarsi al contorto sistema di trasferimento dati tra applicazione e libreria.
Ma se il file fosse mappato a una zona di memoria che è una finestra per un dispositivo hardware che fa le stesse operazioni, allora non si avrebbe nessuna operazione aggiuntiva, perchè già i dati vanno codificati nel formato che l'hardware vuole, e non c'è nessuna decodifica da fare lato cpu.



su hw SGI questo e' il giro del fumo, ampiamente dimostrato essere il modo + efficace e pulito possibile (sopratutto quanto si tratta di super computer), anche perche' si tratta di sistemi NUMAflex, dove la o le CPU e GFX si parlano solo tramite interrupt, e DMA. La applicazione di turno parcheggia  i comandi ed i dati grafici nella pipe della/delle GFX interessate, ci aggiunge anche i puntatori della zona di memoria video condivisa e quando scatta il crossbar event il DMA fa il resto, ovvero si puppa in un sol colpo la lista di cose da fare, i dati da processare, e si mette a processarli rilasciando poi, eventualmente, un interrupt

e' stata per anni la soluzione vincente dalle piccole Workstation ai supercomputer Visualize

la separazione dei compiti e' netta:
  • il kernel si occupa SOLO di infilare il bufferone nello slot giusto del crossbar per farlo arrivare sano alla GFX giusta, non da altre parti, e di raccogliere flag ed interrupt
  • la parte in userspace si occupa SOLO di confezionare quel buffer di comandi nel modo giusto, senza cose bislacche, e di passare pure i puntatori giusti, e sopratutto aggiornati, per la memoria video condivisa

a me personalmente va bene e piace che sia cosi' anche per ridurre la complessità del codice, o mi occupo del kernel e ragiono per buffer, o mi occupo dello user space e ragiono per comandi e servizi per le primitive grafiche

Stessa cosa che fa l'hardware moderno; se leggi la presentazione (http://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead) di NVIDIA che avevo anche linkato prima, vedrai che è proprio come dici.

Purtroppo questo "hack" è necessario, perché non c'è altro modo per inizializzare una scheda grafica VESA e da usare poi col framebuffer.

Ed è una cosa sulla quale mi sto cimentando di recente. Vediamo se ne uscirà fuori qualcosa di utile per AROS.

Avevo lo stesso problema quando lavoravo sul mio kernel hobby: GRUB mi andava comodo perchè mi metteva già in modalità protetta, ma questo significa che non potevo fare le chiamate al BIOS per le funzioni VBE. A suo tempo avevo visto quel trick che faceva X11, e avevo anche una mezza idea di tirargli fuori quella parte di sorgente da usare ai miei scopi, poi però mi son accontentato di far impostare la modalità grafica a un GRUB modificato, e disegnare a mano nel framebuffer.
Avevo anche letto di gente che usava la modalità protetta per creare un "processo" che girava in modalità reale, e lo si usava per far girare il codice del BIOS. È sicuramente un'idea furba e molto interessante, ma credo anche sia abbastanza tricky da far funzionare.

Renderai pubblici i tuoi test? Mi interesserebbe vedere come ne vieni fuori...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 07 Gennaio 2015, 07:03:58
Non hai capito; mi sa che stiamo parlando di cose un po' diverse, perciò mi spiego meglio:
prima di tutto, io sto parlando di questo particolare caso del driver e GPU NVIDIA, e non altre librerie di alto livello (come potrebbe essere la libc ad esempio, o altre librerie di disegno più "interattive" come SDL).

Secondo, un'applicazione OpenGL che usa il driver NVIDIA su Linux funziona circa così:
1) Il driver NVIDIA è composto da due parti: una che lavora kernel-mode (e che  è responsabile della creazione del device /dev/nvidia0), e una parte user-mode (che parla con l'applicazione per esporre tutte le funzioni dell'API).
La parte user non lavora in un suo processo, e quindi sospetto che sia tutto dentro la libreria libGL.so (che, come si capisce dal nome, espone OpenGL), o al massimo ad un'altra libreria che viene caricata da libGL stessa.

2) Le GPU moderne non lavorano con la tecnica di una volta imposta_registri - esegui - imposta_registri - esegui etc, perchè sarebbe una lentezza esorbitante; quello che succede è che lato CPU viene creata una lista di comandi, sotto forma di un bufferone di strutture, che viene inviato in blocco alla GPU tramite DMA; la GPU al suo interno possiede un processore di controllo che interpreta i dati e fa il dispatch dei vari comandi ai vari core di esecuzione parallela.

3) Detto questo, lato CPU abbiamo "solo" il compito di tradurre le chiamate che l'applicazione fa a OpenGL nell'apposito bufferone di comandi; da quanto posso osservare dall'esterno, credo che questa operazione venga fatta solo dal sistema user-mode, quindi da libGL.so diciamo.
Quindi, attraverso /dev/nvidia0 (che ora che ci penso probabilmente è aperto in mmap, quindi non ci sono neanche copie dovute a read() e write()) ci passano solo dati che sono già organizzati per essere inviati alla GPU (e al suo controller interno); quello che la parte kernel-mode deve solo fare è fare un po' di serializzazione in base al PID (nel caso ci siano più applicazioni che usano libGL), e gestire le operazioni di DMA.

Detto questo, un sistema del genere non risente dello "strano" modo di mappare i dispositivi su file tipico degli Unix.
Se dovessimo implementare un sistema del genere tramite una "libreria", si potrebbe fare in due modi diversi (che sono i due punti che avevo elencato sopra):
  • 1) Si tiene la stessa organizzazione di adesso (user fa tutto, kernel gestisce il dma e concorrenza): in questo caso l'unica differenza sarebbe che la parte user e la parte kernel, invece di parlarsi e condividere i bufferoni tramite l'mmap e il /dev/nvidia0, si parlando tramite memoria condivisa (che alla fine è il mmap), e alcune funzioni dedicate alla comunicazione (buffer pronto/ricevi buffer/copia dati etc). Questo credo che sia come viene fatto in Windows ad esempio, che ha il vantaggio di permettersi un driver model molto più "tipico", però (come i benchmark mostrano), questo sistema non è né migliore né peggiore del sistema unix, in quanto il grossissimo del lavoro è fatto in user-mode per la creazione delle liste di comandi, e il piccolo segnale che user deve mandare al kernel per inviare i comandi alla GPU è una percentuale molto piccola del tempo totale da risultare trascurabile.
  • 2) Si mette tutto dentro il kernel che espone direttamente le funzioni OpenGL a mo' di syscall: in questo caso, lato applicazione non si avrebbe più la corposa libGL.so che fa un po' tutto,  ma si avrebbe solo uno stub che a turno usa i metodi del sistema operativo per mandare le chiamate al driver, che così internamente può fare tutte le cose che gli interessano. Questo metodo è evidentemente più lento del sistema precedente, perchè ogni chiamata deve passare per i sistemi di dispatch dell'OS, deve entrare in kernel mode e deve essere ricevuta dal driver; oltretutto, l'applicazione deve essere messa in attesa della fine della chiamata a funzione. Quest'ultimo punto può essere mitigato (e anche molto, in base all'api), se si usa un sistema di message-passing che ammette RPC asincrona: in questo modo, l'applicazione può inviare a raffica molte chiamate a funzione e solo in un secondo momento leggere i valori di ritorno.

Fine. Ricapitolando: in questo particolare caso, il sistema e le condizioni sono tali da non prendere un colpo dal particolare sistema di comunicazione via file descriptor.

Citazione
Non è una dimostrazione formale, ma mio avviso risulta piuttosto chiaro che l'approccio a libreria sia intrinsecamente più efficiente di quello tramite utilizzo di un file "speciale".

Questo è ovvio ("ovvio" non per sminuire quello che hai detto, ma che si spera sia evidente a chiunque nel settore), se parliamo di una libreria generica; praticamente si avrebbe la pesantezza di un sistema di message passing unito alla pesantezza delle operazioni del filesystem.
In questi casi particolari, invece, dove la destinazione di queste informazioni è già un dispositivo hardware che lavora più o meno a stream di byte, la differenza è molto meno sentita, se non annullata.
Riprendiamo l'esempio di legacy: ovviamente quel sistemino lì è molto pesante, perchè l'applicazione, il driver e la CPU devono far lavoro di codifica/decodifica dei dati solo e unicamente per conformarsi al contorto sistema di trasferimento dati tra applicazione e libreria.
Ma se il file fosse mappato a una zona di memoria che è una finestra per un dispositivo hardware che fa le stesse operazioni, allora non si avrebbe nessuna operazione aggiuntiva, perchè già i dati vanno codificati nel formato che l'hardware vuole, e non c'è nessuna decodifica da fare lato cpu.
OK, è tutto chiaro adesso. Avevo capito che /dev/nvidia0 veniva usato per spedire i comandi grafici, che andavano codificati e poi decodificati.

Per quanto hai scritto, non ci sono differenze prestazionali fra l'approccio a file e a librerie in questo caso.
Citazione
Purtroppo questo "hack" è necessario, perché non c'è altro modo per inizializzare una scheda grafica VESA e da usare poi col framebuffer.

Ed è una cosa sulla quale mi sto cimentando di recente. Vediamo se ne uscirà fuori qualcosa di utile per AROS.

Avevo lo stesso problema quando lavoravo sul mio kernel hobby: GRUB mi andava comodo perchè mi metteva già in modalità protetta, ma questo significa che non potevo fare le chiamate al BIOS per le funzioni VBE. A suo tempo avevo visto quel trick che faceva X11, e avevo anche una mezza idea di tirargli fuori quella parte di sorgente da usare ai miei scopi, poi però mi son accontentato di far impostare la modalità grafica a un GRUB modificato, e disegnare a mano nel framebuffer.
Avevo anche letto di gente che usava la modalità protetta per creare un "processo" che girava in modalità reale, e lo si usava per far girare il codice del BIOS. È sicuramente un'idea furba e molto interessante, ma credo anche sia abbastanza tricky da far funzionare.

Renderai pubblici i tuoi test? Mi interesserebbe vedere come ne vieni fuori...
Ehm... non penso proprio. La mia idea è di sviluppare una libreria che esponga delle API che vengono richiamate dal driver che implementa il supporto al VESA (per settare un determinato modo video da BIOS, ed elencare le modalità video disponibili). Compilerò e rilascerò la libreria (o un file oggetto, se qualcosa dovesse servire da linkare nel kernel), ma non i sorgenti. Quelli del driver, invece, saranno giocoforza pubblici causa licenza virale.

Mi spiace, ma non ho intenzione di condividere il mio lavoro con tutti. C'è parecchio da sgobbare, e non voglio svendere la mia professionalità, soprattutto pensando che qualcuno possa sfruttarlo senza che né io né AROS abbia qualcosa in cambio.

Comunque al momento parliamo di ipotesi. Prima che possa capire se funziona o meno, passerà parecchio tempo sperimentando.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 07 Gennaio 2015, 15:36:55
Ehm... non penso proprio. La mia idea è di sviluppare una libreria che esponga delle API che vengono richiamate dal driver che implementa il supporto al VESA (per settare un determinato modo video da BIOS, ed elencare le modalità video disponibili). Compilerò e rilascerò la libreria (o un file oggetto, se qualcosa dovesse servire da linkare nel kernel), ma non i sorgenti. Quelli del driver, invece, saranno giocoforza pubblici causa licenza virale.

Mi spiace, ma non ho intenzione di condividere il mio lavoro con tutti. C'è parecchio da sgobbare, e non voglio svendere la mia professionalità, soprattutto pensando che qualcuno possa sfruttarlo senza che né io né AROS abbia qualcosa in cambio.

Comunque al momento parliamo di ipotesi. Prima che possa capire se funziona o meno, passerà parecchio tempo sperimentando.

Conosco bene come la pensi, per questo ho chiesto. Comunque a me non interessano i sorgenti, ma solo informazioni varie tipo se ti scrivi un emulatore oppure usi il trick del segmento in modalità reale, oppure se hai incontrato comportamenti strani non documentati di cui stare attenti.
Ovviamente se non vuoi neanche discutere di queste cose, non ci sono problemi: lavoro tuo, decisione tua.

pensate che bello il fatto che sulle workstation SGI ed HP non c'e' bisogno di fare quei giri per la "scheda video", hai gia' tutto esposto dal firmware :D

Vabbè, lì ti parte la musichina "ti piace vincere facile? bonsci bonsci bon bon bon"! :P
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 07 Gennaio 2015, 18:43:15
pensate che bello il fatto che sulle workstation SGI ed HP non c'e' bisogno di fare quei giri per la "scheda video", hai gia' tutto esposto dal firmware :D
Lo credo bene: hai solo quella, o comunque pochi modelli, di cui hai pieno controllo.

Pensa, invece, cosa serve per poter cambiare modalità video per TUTTE le schede grafiche esistenti (che supportano VESA e Linear framebuffer, ovviamente: diversamente è tecnologia dell'anteguerra di cui non ha nemmeno senso discutere). O hai i driver del produttore (come capita con Windows, e qualche volta con Linux), oppure piangi in aramaico antico. :-\

Ehm... non penso proprio. La mia idea è di sviluppare una libreria che esponga delle API che vengono richiamate dal driver che implementa il supporto al VESA (per settare un determinato modo video da BIOS, ed elencare le modalità video disponibili). Compilerò e rilascerò la libreria (o un file oggetto, se qualcosa dovesse servire da linkare nel kernel), ma non i sorgenti. Quelli del driver, invece, saranno giocoforza pubblici causa licenza virale.

Mi spiace, ma non ho intenzione di condividere il mio lavoro con tutti. C'è parecchio da sgobbare, e non voglio svendere la mia professionalità, soprattutto pensando che qualcuno possa sfruttarlo senza che né io né AROS abbia qualcosa in cambio.

Comunque al momento parliamo di ipotesi. Prima che possa capire se funziona o meno, passerà parecchio tempo sperimentando.

Conosco bene come la pensi, per questo ho chiesto. Comunque a me non interessano i sorgenti, ma solo informazioni varie tipo se ti scrivi un emulatore oppure usi il trick del segmento in modalità reale, oppure se hai incontrato comportamenti strani non documentati di cui stare attenti.
Ovviamente se non vuoi neanche discutere di queste cose, non ci sono problemi: lavoro tuo, decisione tua.
No, mi limito a non pubblicare i sorgenti. Della soluzione ne posso anche parlare.

Ho scartato la soluzione di creare un segmento/descrittore per eseguire codice in modalità reale o dentro una macchina virtuale 8086, per due motivi: primo perché non funziona su x64, e secondo perché non mi dà pieno controllo per quello che voglio fare.

Per cui vale la prima che hai detto: mi scrivo un emulatore 8086 "nudo e crudo" (niente 80186 o altre migliorie). Il minimo indispensabile per far girare il codice del BIOS della scheda video installata, in modo da recuperare facilmente l'elenco delle modalità video, e di settare quella desiderata.

Al momento penso di svilupparlo in Python, per una questione di velocità di modellazione. Tanto per queste cose non mi serve assolutamente la velocità d'esecuzione, ma vedere se l'emulatore si comporta bene e fa il suo lavoro correttamente.

Una volta verificato funzionamento, converto paro paro il codice in C nudo e crudo, e "sufficientemente portatile". Quest'ultimo significa che al momento il codice sarà esclusivamente little-endian, ma farò uso di macro per accedere a word/16-bit, in modo da rendere molto semplice l'eventuale porting su altre architetture.

Soltanto per Windows, penso di incapsulare il tutto dentro una DLL, in modo da poter riciclare il codice di unit-testing che scriverò in Python. Specialmente per queste cose, lo unit-testing è fondamentale. Anche perché mi consente di sperimentare nuove implementazioni senza l'incubo di aver introdotto qualche bug.

Al momento è tutto, ma di carne al fuoco e pensieri ce n'è già abbastanza. Ho in mente anche altre soluzioni per migliorare la velocità d'esecuzione (che comunque, per quel che deve fare il progetto, non è assolutamente importante), ma è decisamente prematuro parlarne. ;)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 07 Gennaio 2015, 22:17:28
Ho scartato la soluzione di creare un segmento/descrittore per eseguire codice in modalità reale o dentro una macchina virtuale 8086, per due motivi: primo perché non funziona su x64, e secondo perché non mi dà pieno controllo per quello che voglio fare.

Ah già, questa cosa me la ero dimenticata; probabilmente per lo stesso motivo pensavo di riusare il codice dell'emulatore di X, ma son passati alcuni anni e non mi ricordo proprio cosa avevo pensato a quel tempo...

Per cui vale la prima che hai detto: mi scrivo un emulatore 8086 "nudo e crudo" (niente 80186 o altre migliorie). Il minimo indispensabile per far girare il codice del BIOS della scheda video installata, in modo da recuperare facilmente l'elenco delle modalità video, e di settare quella desiderata.

E prendere il codice da qualche altra parte? Ad esempio da DOSBox, o da Bochs? Ti velocizzerebbe tantissimo lo sviluppo.
(Ovviamente devi fare una veloce indagine e capire se il codice è abbastanza modulare da essere spostato dal progetto originale a questa nuova occupazione, e solo in caso negativo metterti a scrivere il tuo emulatore)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 07 Gennaio 2015, 22:25:51
Il problema è la licenza: il primo è GPL, e il secondo LGPL. Io voglio poterci fare quello che voglio col mio codice, senza essere costretto a rilasciarlo...

Poi non ti nascondo che smanettare con queste cose mi gasa molto: adoro lavorare con roba a così basso livello. :D
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 07 Gennaio 2015, 23:41:49
Perdonami, Carlo, ma quando hai le mani libere puoi fare quello che vuoi e inventarti il sistema più bello e fico del mondo.

Il PC si porta dietro la progettazione del primo modello targato IBM, che è stato via via espanso/esteso aggiungendo nuove funzionalità, ma preservando la famigerata retrocompatibilità.

Col senno di poi è facile dire cosa sarebbe stato meglio fare...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 08 Gennaio 2015, 00:00:10
no, il punto e' un altro: io non ci spenderei 2 minuti su quella roba, ovvero farei come ti ha suggerito tra le righe Z80fan, ovvero la prima ciabatta gia' fatta, e pedalare
E' roba GPL, per cui incompatibile con le mie esigenze.
Citazione
perche' per come la vedo io, se devo investirci tempo, deve essere na roba che non mi da fastidio viscerale
Ma io mi sto divertendo. ;D
Citazione
che poi, c'e' pure da vedere se a presentare solo i binari non ti facciano storie sul fatto che vogliono anche il sorgente senno che roba opensource e' ?

provato sulla mia pelle: e al posto degli elogi (per ripagarsi almeno della fatica) arrivano i calci in culo (tipico, tra parentesi dei talebani dell'openqualsiasi, non so quanti ce ne siano anche in AROS, in linux &C sono tutti fissati) , per cui .. 2 motivi per dire anche no, o meglio, pigliatevi la ciabatta, e zitti  :D
Nel mondo AROS non sono tutti talebani dell'open source, fortunatamente. Icaros, che è la "distro" più diffusa e apprezzata, integra parecchia roba di cui gli autori forniscono soltanto i binari. ;)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: TheKaneB - 08 Gennaio 2015, 10:15:07
su AROS e sul mondo Amiga in generale l'Open Source è arrivato abbastanza tardi, per cui gli utenti e sviluppatori non ne hanno un attaccamento particolare. Nascere lontano dalle università ha i suoi pregi :D
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: TheKaneB - 08 Gennaio 2015, 10:50:02
@dsar
no, secondo me bisogna valutare i costi di progetto, nel senso che ai tempi del bios dei PC che ci portiamo ancora oggi dietro c'erano gia' soluzioni nettamente migliori, se vado a guardare gli stessi tizi di IBM su un S/36 sembrano dimostrare che quando si scuciono assegni con diversi zeri le faccende fanno la differenza tra la cioccolata e la cacca, stesso colore, sono sempre computer  :o :o :o

eh si, ma i sistemi s/360 costavano nell'ordine delle centinaia di migliaia di dollari, mentre il PC era sotto i 5 mila. Non puoi confrontarli, ma mai nella vita :D
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 08 Gennaio 2015, 15:34:06
soluzione3, come le motorola EVS, pero' costava una standard forzato delle classi dei devices, motorola di fatto ha imposto la cosa con la linea industriale VME, e tutti si sono adeguati senno calci in culo rotanti, i PC IBM invece … hanno aperto le porte ai cloni e cosi', con la storia che cani e porci potevano metterci mano, ognuno ha fatto quello che voleva, e quindi senza BIOS extension non se ne veniva fuori

Il problema (tecnico) è che l'8086 (8088 in realtà) che aveva il PC IBM poteva indirizzare al massimo 1 MB di memoria, a differenza dei 4 GB del 68000, quindi è difficile se non impossibile riservare degli spazi così grandi di indirizzamento senza poi bloccare l'espansione di RAM (che a un certo punto incontra gli slot dei dispositivi e quindi non può più aumentare).
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 08 Gennaio 2015, 16:19:21
quello sicuramente nel 8086, poi' pero' con i 32bit … siamo rimasti legati

Ovvio, per colpa della famigerata retrocompatibilità. Hardware a 32 bit è arrivato molto prima del software che ne faceva pieno uso (il 386 è della metà degli '80, ma non è prima di Windows 95 e NT che si è finalmente avuto un vero supporto a 32 bit su hardware consumer e pro-consumer), quindi l'hardware doveva rimanere 100% compatibile con tutto il software precedente.

cioe' tu dimmi, oggi, con addirittura 64 bit, siamo ancora alla bios extension
mica ho voglia io di andare a ravanare OGGI in quelle faccende

Ma infatti le VBE (Vesa Bios Extensions) non le usa nessuno (commercialmente), vanno tutti di driver VGA di default (tutte le GPU partono in modalità VGA-compatibile e si attivano solo quando ricevono i segnali magici dai diver) o di driver del produttore.

Il fatto che le VBE siano state fatte male è ovvio, anche perchè l'ultima versione è del 1998, anno in cui tranquillamente la maggioranza di PC erano a 32 bit (e di sicuro quelli che avrebbero incluso le VBE sarebbero stati più nuovi ancora), quindi non ha senso che avessero incluso un sistema da usare solo in modalità reale*.

* In realtà *c'è* una modalità per usare le VBE in modalità protetta, ma già sono usate talmente poco che i produttori le implementano in modo molto sommario, quindi a meno di non avere proprio un dispositivo fatto bene penso siano praticamente inutili.

Citazione
sul serio, e' tutto lavoro inutile, una perdita di tempo che non ha senso a cominciare dal design

meglio stare su hw SLOTed, no ?
a meno che sia per lavoro, dove … mi posso pure tappare il naso
ma per hobby decisamente no

Se vuoi stare su PC, questo ti tocca. E comunque, i progetti "per hobby" non stanno a rompersi il cazzo e si impostano un framebuffer lineare durante il bootloader (fatto a mano oppure lo fa fare a GRUB), e poi vanno di puntatore in memoria; alla fine, "per hobby" interessa che appaia qualcosa sullo schermo, se poi non hai l'accelerazione hardware pazienza.
http://wiki.osdev.org/Drawing_In_Protected_Mode
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 08 Gennaio 2015, 19:00:18
Carlo, come ti è stato detto, non puoi parlare di altre soluzioni col senno di poi. Il PC è nato nel 1981, e tu parli di una soluzione di Motorola di OTTO anni dopo. E parli pure di soluzioni multiplatform, con architetture diverse. Mi spiace, ma non ha alcun senso.

Se ti vai a vedere le caratteristiche del primo PC, capisci perché le cose sono state fatte in quel modo. Il PC è figlio di quel periodo, con tutte le problematiche del caso e i limiti che, purtroppo, si trascinava dietro. Per giunta la scansione delle ROM, da parte del BIOS, a caccia di nuovi dispositivi da (far) inizializzare è stata aggiunta soltanto un anno dopo: prima non c'era nemmeno quella!

Le estensioni VESA sono figlie di quel periodo e della retrocompatibilità che è stata già citata da Z80Fan. Mettiti nei panni dei produttori di schede video. Come fare a far supportare le proprie, mantenendo la compatibilità con tutto l'esistente? Piazzi la tua ROM a C8000 (mi pare), e sfrutti il meccanismo del BIOS per integrarti nel sistema ed esporre i tuoi servizi.

Poiché il numero di schede video è letteralmente esploso, puoi immaginare quanti casini sono nati per questo, ma che vengono risolti alla radice: supportando il vetusto meccanismo del VGA (in realtà EGA, perché è nato con questa scheda video) BIOS.

Se non vuoi usarlo, vuol dire che sei fortunato: puoi contare sui driver video appositamente sviluppati per evitare questo vetusto meccanismo, e magari sfruttare tutte le caratteristiche della scheda. Se non sei fortunato, non hai altra scelta che il VESA; e se è vero che X11 ha qualche meccanismo di emulazione 8086 per farlo, vuol dire che persino Linux non è messo così bene a livello di driver nativi per le schede grafiche.

Figuriamoci, quindi, AROS, che non ha nemmeno quello!
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 08 Gennaio 2015, 19:05:27
Il problema (tecnico) è che l'8086 (8088 in realtà) che aveva il PC IBM poteva indirizzare al massimo 1 MB di memoria, a differenza dei 4 GB del 68000
Giusto una precisazione: i 68000 supportano 16MB al massimo. 64MB partizionando lo spazio d'indirizzamento fra modalità supervisore / utente, e fra accesso a codice o dati.

Per il resto concordo su tutto (ed è il motivo per cui non me ne frega niente dell'eventuale VBE in modalità protetta: real mode 8086 forever!)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Z80Fan - 08 Gennaio 2015, 19:12:39
Giusto una precisazione: i 68000 supportano 16MB al massimo. 64MB partizionando lo spazio d'indirizzamento fra modalità supervisore / utente, e fra accesso a codice o dati.

Si si lo sapevo, ma non era proprio importantissimo e non volevo appesantire il discorso; è pur sempre un ordine di grandezza in più. :P
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: paolone - 04 Febbraio 2015, 21:40:09
Citazione
che poi, c'e' pure da vedere se a presentare solo i binari non ti facciano storie sul fatto che vogliono anche il sorgente senno che roba opensource e' ?

provato sulla mia pelle: e al posto degli elogi (per ripagarsi almeno della fatica) arrivano i calci in culo (tipico, tra parentesi dei talebani dell'openqualsiasi, non so quanti ce ne siano anche in AROS, in linux &C sono tutti fissati) , per cui .. 2 motivi per dire anche no, o meglio, pigliatevi la ciabatta, e zitti  :D

Nel mondo AROS non sono tutti talebani dell'open source, fortunatamente. Icaros, che è la "distro" più diffusa e apprezzata, integra parecchia roba di cui gli autori forniscono soltanto i binari. ;)

Il punto è molto semplice: se si vuole integrare qualcosa di proprio in AROS, *DEVE* essere rilasciato open source con una licenza APL compatibile.

Se invece deve essere incluso in Icaros Desktop, *me ne strafotto* se è disponibile solo il codice binario, e se mi aiuta / migliora il sistema, ce lo metto lo stesso, basta che sia free e liberamente distribuibile. In altre parole: l'open source per me è un mezzo per arrivare a uno scopo, non il fine in se stesso, cosa che invece sembra provocare erezioni istantanee ai freetards di ogni dove.

Preferisco che una cosa sia open per la sola ragione che, se un giorno l'autore originale si rompe i coglioni di portarla avanti, o non può farlo perché il traghetto su cui navigava viene centrato dalla fusoliera di un aereo che precipita, almeno qualcun altro può portarlo avanti.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 04 Febbraio 2015, 21:46:47
Capisco perfettamente le tue ragioni, ma posso dirti in tutta sincerità che non mi va di cedere liberamente il frutto di tante ore strappate ai fine settimane e soprattutto al sonno. Comunque ho ancora una montagna di lavoro che mi attende prima di vedere qualche risultato, per cui affronteremo meglio quest'argomento quando/se avrò per le mani qualche risultato concreto: per il momento continuo a sputare sangue e vado avanti.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: lucommodore - 05 Febbraio 2015, 00:09:37
Ma non c'è più nessuno che faccia le cose per il bene dell'umanità?  :-\
E Goldrake? Non ci ha insegnato proprio niente Goldrake? :'(
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Nonefonow - 05 Febbraio 2015, 00:23:25
AROS (almeno per il momento) non mi sembra un progetto fatto a scopi di lucro. 
 
Se poi si tolgono anche tutti i benefici potenziali (o vari diritti o ? ? ?) per via della "open source" e della compatibilita' con APL, secondo me, diventa ancora piu' difficile invogliare i programmatori / sviluppatori.
 
Capisco il discorso di paolone per via del fatto che qualcuno si puo' stancare del progetto.  Pero' senza un minimo di incentivazione (e non necessariamente monetaria) ci si ritrova di fronte alla posizione di cdimauro.
 
Forse si potrebbe trovare una via di mezzo. 
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 05 Febbraio 2015, 01:13:02
Ma non c'è più nessuno che faccia le cose per il bene dell'umanità?  :-\
E Goldrake? Non ci ha insegnato proprio niente Goldrake? :'(

Goldrake - er il Dottor Procton si beccava sovvenzioni sottobanco da JSDF NATO e COMECON visto che loro non potevano fare una mazza, o come pensi che abbia restaurato l'istituto, costruito delfino spaziale e talpa, dato i dindini a Koji/Alcor per costruire il G2? ^^

OK,c'era anche Actarus che posava come sirenetto per le riviste nipponiche stile playmen (rigorosamente con elmo chiuso pero' causa identita' segreta) e pure quello portava un certo introito... :P

Decisamente piu' sfigato il cugino che approdo' dalle parti nostre: (mal) pagato dai servizi segreti locali e ignorato dalla CIA si occupava di sventare trame terroristiche usando come copertura (e principale fonte economica) una ditta di detersivi... ma questa e' un'altra storia!
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Febbraio 2015, 06:09:51
AROS (almeno per il momento) non mi sembra un progetto fatto a scopi di lucro. 
 
Se poi si tolgono anche tutti i benefici potenziali (o vari diritti o ? ? ?) per via della "open source" e della compatibilita' con APL, secondo me, diventa ancora piu' difficile invogliare i programmatori / sviluppatori.
 
Capisco il discorso di paolone per via del fatto che qualcuno si puo' stancare del progetto.  Pero' senza un minimo di incentivazione (e non necessariamente monetaria) ci si ritrova di fronte alla posizione di cdimauro.
 
Forse si potrebbe trovare una via di mezzo.
Per quanto mi riguarda non è una questione monetaria. Non avrei alcun problema a rilasciare il tutto (ma PRIMA devo vedere cosa ne pensa l'azienda: anche se fuori dall'ufficio, se metto le mani su qualcosa che potrebbe rientrare nella sua sfera di competenza, non mi appartiene. Comunque coi legali me la vedrò dopo) SE il mio lavoro fosse utilizzabile ESCLUSIVAMENTE in seno ad AROS e alla sua comunità.

Invece con l'APL ne perderei i diritti e chiunque potrebbe farci quello che vuole anche al di fuori di AROS (magari proprio da OS4 o MorphOS, ma in generale chiunque sviluppi un nuovo s.o. potrebbe trarne vantaggio).

Non ho voglia di dar da mangiare agli sciacalli che mangiano da AROS senza dar nulla indietro.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 05 Febbraio 2015, 08:10:59
AROS (almeno per il momento) non mi sembra un progetto fatto a scopi di lucro. 
 
Se poi si tolgono anche tutti i benefici potenziali (o vari diritti o ? ? ?) per via della "open source" e della compatibilita' con APL, secondo me, diventa ancora piu' difficile invogliare i programmatori / sviluppatori.
 
Capisco il discorso di paolone per via del fatto che qualcuno si puo' stancare del progetto.  Pero' senza un minimo di incentivazione (e non necessariamente monetaria) ci si ritrova di fronte alla posizione di cdimauro.
 
Forse si potrebbe trovare una via di mezzo.
Per quanto mi riguarda non è una questione monetaria. Non avrei alcun problema a rilasciare il tutto (ma PRIMA devo vedere cosa ne pensa l'azienda: anche se fuori dall'ufficio, se metto le mani su qualcosa che potrebbe rientrare nella sua sfera di competenza, non mi appartiene. Comunque coi legali me la vedrò dopo) SE il mio lavoro fosse utilizzabile ESCLUSIVAMENTE in seno ad AROS e alla sua comunità.

Invece con l'APL ne perderei i diritti e chiunque potrebbe farci quello che vuole anche al di fuori di AROS (magari proprio da OS4 o MorphOS, ma in generale chiunque sviluppi un nuovo s.o. potrebbe trarne vantaggio).

Non ho voglia di dar da mangiare agli sciacalli che mangiano da AROS senza dar nulla indietro.

Discorso complicato,anche perche' in realta' anche il "dare da mangiare agli sciacalli" avrebbe a lungo termine vantaggi intesi come aumento della base utente: probabilmente un approccio giusto sarebbe fare una parte delle infrastrutture non critica libera e del core distribuirne solo i binari si che se altri vogliono usare la parte libera devono farsi il core per conto loro...
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Nonefonow - 05 Febbraio 2015, 15:54:21

Invece con l'APL ne perderei i diritti e chiunque potrebbe farci quello che vuole anche al di fuori di AROS (magari proprio da OS4 o MorphOS, ma in generale chiunque sviluppi un nuovo s.o. potrebbe trarne vantaggio).


Ma nell' APL esiste il principio d'etica di reciprocita'  (?).  Quindi chiunque potrebbe trarre vantaggio per AROS da quello che e' fatto in OS4 e MorphOS.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Febbraio 2015, 18:18:20
No, non esiste. L'unico obbligo dell'APL è che se cambi una parte di codice devi pubblicare quelle modifiche che hai effettuato (se rilasci dei binari che ne fanno uso).
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Febbraio 2015, 18:21:50
[...]Non ho voglia di dar da mangiare agli sciacalli che mangiano da AROS senza dar nulla indietro.

Discorso complicato,anche perche' in realta' anche il "dare da mangiare agli sciacalli" avrebbe a lungo termine vantaggi intesi come aumento della base utente:
Francamente non vedo come potrebbe succedere. Prendere i sorgenti di AROS servirebbe, al contrario, a rinforzare la "concorrenza".
Citazione
probabilmente un approccio giusto sarebbe fare una parte delle infrastrutture non critica libera e del core distribuirne solo i binari si che se altri vogliono usare la parte libera devono farsi il core per conto loro...
Purtroppo la parte più interessante e utile è proprio quella critica, altrimenti nemmeno ci si porrebbe il problema.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 05 Febbraio 2015, 18:30:49
[...]Non ho voglia di dar da mangiare agli sciacalli che mangiano da AROS senza dar nulla indietro.

Discorso complicato,anche perche' in realta' anche il "dare da mangiare agli sciacalli" avrebbe a lungo termine vantaggi intesi come aumento della base utente:
Francamente non vedo come potrebbe succedere. Prendere i sorgenti di AROS servirebbe, al contrario, a rinforzare la "concorrenza".

Be' siccome TUTTA la userbase amighista e' a rischio di estinzione per cause naturali (niente nuovo hw, politiche liberticide, niente nuovi utenti) alla fine tutto fa brodo; ho gia' ribadito che non sono ad principium contro os4 o morphos, piuttosto contro politiche e business plan scellerati, utenti sprovveduti e il dannato Ego dei programmatori e sviluppatori che ci lavorano :( e cmq se (quando) le entita' commerciali crollano AROS invece rimane

Purtroppo la parte più interessante e utile è proprio quella critica, altrimenti nemmeno ci si porrebbe il problema.

Se parliamo di qualcosa fatto in Python, os4 e mos hanno le loro implementazioni gia' - quella di os4 e' piu' avanzata con diverse librerie portate e con binding a reaction e ho idea che morphos abbia anche lui qualcosa di simile; AROS e' l'uinico che non ha una versione avanzata di Python
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: cdimauro - 05 Febbraio 2015, 18:36:23
Francamente non vedo come potrebbe succedere. Prendere i sorgenti di AROS servirebbe, al contrario, a rinforzare la "concorrenza".

Be' siccome TUTTA la userbase amighista e' a rischio di estinzione per cause naturali (niente nuovo hw, politiche liberticide, niente nuovi utenti) alla fine tutto fa brodo; ho gia' ribadito che non sono ad principium contro os4 o morphos, piuttosto contro politiche e business plan scellerati, utenti sprovveduti e il dannato Ego dei programmatori e sviluppatori che ci lavorano :(
Per cui... chi se ne frega di loro? A maggior ragione visto che AROS è trattato male dalle due comunità.
Citazione
e cmq se (quando) le entita' commerciali crollano AROS invece rimane
Benissimo. Allora perché preoccuparsi degli altri? Perché dargli la possibilità di sfruttare il lavoro di AROS?
Citazione
Purtroppo la parte più interessante e utile è proprio quella critica, altrimenti nemmeno ci si porrebbe il problema.

Se parliamo di qualcosa fatto in Python, os4 e mos hanno le loro implementazioni gia' - quella di os4 e' piu' avanzata con diverse librerie portate e con binding a reaction e ho idea che morphos abbia anche lui qualcosa di simile; AROS e' l'uinico che non ha una versione avanzata di Python
Lo so, ma non è Python: http://www.nonsoloamiga.com/index.php?topic=2939.msg52351#msg52351

Comunque, sì, ci sarebbe anche bisogno di un Python aggiornato. Vedremo, in futuro.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Nonefonow - 15 Maggio 2015, 19:20:29
Comunque e' interessante quello che stanno facendo su Haiku. 

http://www.haiku-os.org/development

C'e' una pagina chiara di istruzioni per chi volesse sviluppare per quel S.O. 

e una pagina di documentazione http://www.haiku-os.org/guides

Tra l'altro partecipano al Google Code-In. 

Solo alcune idee per il gruppo AROS.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Dolcetto - 20 Giugno 2015, 19:08:03
Allora, mi son letto tutta la discussione, e devo ammettere che la trovo davvero interessante (anche perché pare ci sia qualcuno che sa di cosa si sta parlando, dall'altra parte).
Se posso esprimere la mia opinione (per quanto naif, magari), per AROS bisognerebbe partire dalla macchina fisica. Ora, il sistema che più mi gasa, al momento è IcarOS Desktop. Esiste una lista di hardware compatibile, non esistono build (forse si potrebbe fare riferimento agli AresOne, ma anche quello è un mezzo salto nel buio, dato che non è che l'hardware sia esplicitato tanto tanto), e senza la macchina su cui funziona tutto, dove vogliamo andare? A questo punto mi sentirei di proporre un modello stile Apple, poche build di facile assemblaggio su cui si sa per certo che il sistema girerà da usare come base di partenza funzionante al 100%.
Altra cosa, la documentazione. Sono una capra, in materia, eppure vorrei davvero tentare di scrivere qualcosa per IcarOS, una utility, contribuire a Cinnamon, fare un porting di OpenOffice, qualcosa. Ma confesso anche che non so neppure lontanamente da dove iniziare.  :-[
Altro punto dolente mi pare sia la virtualizzazione... dal momento che la 2.0.3 è implosa, sto cercando di farla girare. Potrebbe essere utile diffondere una immagine disco di VirtualBox pronta da scaricare ed usare?
Questo è quanto, per ora, spero solo di non fare la figura dell'ingenuotto (poi, appena riesco finalmente a provarlo, mi farebbe piacere recensirlo sul mio blog).
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Allanon - 21 Giugno 2015, 00:00:30
IcAROS 2.0.3 a me gira perfettamente sia su VirtualBox che su VMWare, installazione rapidissima e distro imponente e molto curata :)
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Nonefonow - 21 Giugno 2015, 01:50:15
Io preferisco farci  una installazione complete su disco fisso.  Mi gira benissimo cosi'.  Unica cosa che ancora non sono riuscito a fare e' accedere alla rete.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Nonefonow - 21 Ottobre 2015, 16:56:31
E adesso grazie alle dritte di saimon69 e di un'utenete sul forum AROS sono anche nella rete.

Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: paolone - 30 Ottobre 2015, 15:36:54
E adesso grazie alle dritte di saimon69 e di un'utenete sul forum AROS sono anche nella rete.

Beh dai, ci sono voluti solo 4 mesi ma ne è valsa la pena, dì la verità!
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: Nonefonow - 30 Ottobre 2015, 16:42:18
21 Giugno - 21 Ottobre. Strana coincidenza, non l'avevo notato.   

In effetti con OWB e' molto piacevole  navigare in rete.
Titolo: Re:Come si invogliano nuovi dev a mettere mani in AROS?
Inserito da: saimon69 - 12 Gennaio 2016, 23:20:54
Cesare e' riuscito a creare una bounty per aggiornare lo stato di PyAROS, sperando si aggiungano bounties per le librerie in seguito.
Aggiungo il link qui:

PyAROS Advanced - Power2People.org (http://power2people.org/projects/pyaros/)