Radio Devention 8/8S - firmware OpenSource

[system450]

Provati walkera cb100 col protocollo wk2401 e Blade MSR col protocollo dsm2.
L'ho tenuta accesa parecchio tra settaggi, mix, dual rate, curve varie e 4 lipo in tutto e non ho avuto alcun problema di riavvii o bloccaggi o perdite di controllo.
Sto usando la nights revision del 7 luglio 2013.
Per il momento tutto ok. Persino il bind lento senza id fixed walkera del cb100 è molto più veloce che col firmware walkera originale.
Quello dell'msr è velocissimo e funziona con l'id fixed.

Farò altre lipo coi piccolini prima di decidere se usarlo in modo definitivo o no, ma per il momento sono soddisfatto !

[eriskio]

Originalmente inviato da romoloman

Scusa perchè non sbacare l'esistente ?
I fork senza introdurre modifiche sono generalmente quanto più dannoso e dispendioso possa esistere per un progetto opensource.

Quando Bertrand ed io abbiamo fatto il fork di opentx (all'epoca open9x) era per aggiungere feature e modifiche che non erano ben accette nel progetto originale.
Se era solo per fare debugging saremmo rimasti in gruvin9x.

No, ed è il motivo per cui esistono (e mi piacciono) progetti come FreeBSD, OpenBSD e NetBSD: il primo traina lo sviluppo, gli altri "specializzano" (sicurezza e stabilità l'uno e portabilità l'altro).
La fase di stabilizzazione di un software "complesso", specie se non eseguito da integratori specialisti ma da una base piu' o meno larga di sviluppatori e utenti, deve fare tesoro delle esperienze personali.
Il trovare e risolvere un baco, dovrebbe portare alla scrittura di uno (o piu') test di non regressione anzitutto, cosa che sui progetti opensource delle radio finora non ho visto fare. questo perchè ogni singola modifica al codice anche minima potrebbe portare ad un disastro; insomma ritengo che debba esistere un sistema organico di test automatico delle funzionalità (come esiste nei progetti industriali).
Fare un fork significa freezare (bloccare) lo sviluppo ad un certo punto, stabilizzandolo il piu' possibile da un lato per offrire un prodotto finito e serio, ma lasciando contemporaneamente che chi sviluppa nuove funzionalità possa continuare liberamente a farlo.
Purtroppo la perfezione nello scrivere codice è molto di là da venire, e qualche bachetto scappa sempre anche ai piu' meticolosi, precisi e bravi programmatori.
Tu mi dirai che questo può essere fatto solo con una branch nel repository centrale: vero ma forse è meglio duplicare permettendo a ciascuno di essere libero di agire secondo la propria disponibilità di tempo/risorse e poi riallineandosi secondo esigenza che non obbligarsi ad un inseguimento continuo e senza senso.
Per inciso, se stabilizzo un pezzo un di codice, non mi posso permettere il lusso di doverlo rivedere perchè nel frattempo qualcuno mi ha fatto un merge per disegnare qualche faccina in piu' sul display...
Ovviamente questo è frutto di mia personale esperienza/abitudine ed è quindi assolutamente una visione personale.

Ciao

[romoloman]

Originalmente inviato da eriskio

No, ed è il motivo per cui esistono (e mi piacciono) progetti come FreeBSD, OpenBSD e NetBSD: il primo traina lo sviluppo, gli altri "specializzano" (sicurezza e stabilità l'uno e portabilità l'altro).
La fase di stabilizzazione di un software "complesso", specie se non eseguito da integratori specialisti ma da una base piu' o meno larga di sviluppatori e utenti, deve fare tesoro delle esperienze personali.
Il trovare e risolvere un baco, dovrebbe portare alla scrittura di uno (o piu') test di non regressione anzitutto, cosa che sui progetti opensource delle radio finora non ho visto fare. questo perchè ogni singola modifica al codice anche minima potrebbe portare ad un disastro; insomma ritengo che debba esistere un sistema organico di test automatico delle funzionalità (come esiste nei progetti industriali).
Fare un fork significa freezare (bloccare) lo sviluppo ad un certo punto, stabilizzandolo il piu' possibile da un lato per offrire un prodotto finito e serio, ma lasciando contemporaneamente che chi sviluppa nuove funzionalità possa continuare liberamente a farlo.
Purtroppo la perfezione nello scrivere codice è molto di là da venire, e qualche bachetto scappa sempre anche ai piu' meticolosi, precisi e bravi programmatori.
Tu mi dirai che questo può essere fatto solo con una branch nel repository centrale: vero ma forse è meglio duplicare permettendo a ciascuno di essere libero di agire secondo la propria disponibilità di tempo/risorse e poi riallineandosi secondo esigenza che non obbligarsi ad un inseguimento continuo e senza senso.
Per inciso, se stabilizzo un pezzo un di codice, non mi posso permettere il lusso di doverlo rivedere perchè nel frattempo qualcuno mi ha fatto un merge per disegnare qualche faccina in piu' sul display...
Ovviamente questo è frutto di mia personale esperienza/abitudine ed è quindi assolutamente una visione personale.

Ciao

Per il primo neretto guarda la quintalata di gtest code presente in opentx...
Prima di dire che nessuno ha messo regression test guarda bene il codice: se non li vedi mi sa che è un tuo problema....

Riguardo al fork sono assolutamente contrario, infatti vedo una grossa differenza fra branch e fork..
opentx-frsky è un branch stabile da noi gestito per conto di frsky. ma ci consente di lavorare ancora tutti assieme.
Proprio gli esempi che hai portato di sistemi operativi che hanno avuto parecchi fork dovrebbero farti vedere con facilità come il livello di supporto di nuovo hardware presente, a causa della dispersione di risorse umane, non sia neanche paragonabile a quello di linux che di fork del kernel non ne ha avuti, la stessa cosa l'ho vissuta fra libreoffice e openoffice

Poi ognuno fa quello che vuole...
Buon lavoro...

[matrixFLYER]

Raga ma voi di Open tx non potete dare una mano agli sviluppatori di devention??? :cool:

[klamath]

Originalmente inviato da matrixFLYER

Raga ma voi di Open tx non potete dare una mano agli sviluppatori di devention??? :cool:

le devention gliele paghi tu?

[romoloman]

Originalmente inviato da matrixFLYER

Raga ma voi di Open tx non potete dare una mano agli sviluppatori di devention??? :cool:

Già ora sarebbe impossibile,
1) pur essendo in un numero rilevante di persone lo sviluppo di opentx/companion assorbe gran parte del tempo libero e delle nottate.
2) anche se quelli di devention dicono di essersi ispirati come codice a er9x/open9x il codice è talmente diverso che ristudiarlo tutto richiederebbe del gran tempo
3) l'idea di portare opentx anche sulle devo ci era pure balenata nel cervello, ma:
a) quale devo ? Sono profondamente diverse fra loro e ogni port richiede del gran tempo.
b) chi ci paga l'hardware ? Anche prendendo i 4 core developers (Bertrand, Romolo, Mike , André) e pensando a due tipologie di Devo non partono meno di 2000€ di materiale.

ce n'est pa possible... (come direbbe il mio amico Bertrand)

[matrixFLYER]

Ok raga, era una mezza battuta

Io sto per ricevere la Devo 10. Posso fare per lo meno da beta tester!

[eriskio]

Originalmente inviato da romoloman

Per il primo neretto guarda la quintalata di gtest code presente in opentx...
Prima di dire che nessuno ha messo regression test guarda bene il codice: se non li vedi mi sa che è un tuo problema....

Riguardo al fork sono assolutamente contrario, infatti vedo una grossa differenza fra branch e fork..
opentx-frsky è un branch stabile da noi gestito per conto di frsky. ma ci consente di lavorare ancora tutti assieme.
Proprio gli esempi che hai portato di sistemi operativi che hanno avuto parecchi fork dovrebbero farti vedere con facilità come il livello di supporto di nuovo hardware presente, a causa della dispersione di risorse umane, non sia neanche paragonabile a quello di linux che di fork del kernel non ne ha avuti, la stessa cosa l'ho vissuta fra libreoffice e openoffice

Poi ognuno fa quello che vuole...
Buon lavoro...

Primo neretto: sarà un mio problema, ma ho girato un po' il codice di OpenTX ma di Suite di Test automatici, - ma che dico Suite? test! - non ne ho visto neanche l'ombra.
Dove sono i programmi di test (ovviamente da fare girare sul buildato) per evidenziare eventuali regressioni? Quale tool è stato usato?
Fammi sapere.

Secondo neretto: Linux più che supportare "pasticcia" la funzionalità di un'infinità di periferiche.
E' per quello che - persa la voglia di smanettare - Linux lo si abbandona. Perchè?
Potrei anche spiegarlo ma non è il posto per scrivere un trattato.
Il PC è un utensile come lo sono il coltello e la forchetta: per usarli non bisogna conoscere la teoria degli acciai speciali e della tempra.

Vero che le famiglie BSD sono meno aggiornate, ma sono infinitamente piu' concrete e solide. E quando viene rilasciata una versione è quella, è una e le cose si fanno ad UN SOLO modo (non n-mila modi diversi). La sicurezza del sistema è dichiarata, consolidata e provata, non è chiaccherata (e se devi mettere su qualcosa che stia in piedi per anni facendo un servizio serio...)
Poi per carità hai ragione: ognuno fa' quello che vuole.
E non sono certo io a criticare qualcuno, per carità.
Tieni però presente che il bello (e il primo desiderata di Stallman) era proprio il fork e non il branch

Ciao

[-c3po-]

ordinata la devo10.

presto vi tartasserò di domande,
anzi...

ho dovuto prendere quella con stick del gas a sinistra,
mentre io volo in mode3...
ci sono precauzioni/accortezze da rispettare per la conversione?
tks.

[system450]

Originalmente inviato da -c3po-

ordinata la devo10.

presto vi tartasserò di domande,
anzi...

ho dovuto prendere quella con stick del gas a sinistra,
mentre io volo in mode3...
ci sono precauzioni/accortezze da rispettare per la conversione?
tks.

Mi raccomando ! Installa l'ultima nightly build che è derivata dalla 3.00, ma ne corregge i bug/riavvii.