Ho letto 2 email in cui si parla di separare la radio dalla logica di routing; forse per capire dovresti rileggere con piu' calma il thread.
Il giorno 11 gennaio 2013 15:30, Alessandro Gnagni <[email protected]>ha scritto: > Ma che c'entra tutto questo? > Uso opportunistico dell'etere? > Gente arrosita? > Ma di che parliamo? > Ma stiamo parlando delle sdk di airos e delle nuove policy di > distribuzione non di discorsi filosofici... > > Inviato da Sgs 2 > Il giorno 11/gen/2013 08:46, "Michele Favara Pedarsi" <[email protected]> > ha scritto: > > Ci sono decine di buoni motivi per non mettere "chip e ram di routing" sul >> tetto; dall'esposizione alle intemperie (es: fulmine), all'esposizione alle >> "intemperie antropiche" (es: quando una parte della community meganetwork >> preferi' mollare il progetto di rete cittadina per uno sfruttamento >> opportunistico dell'etere modello operatore, digerii male per una settimana >> somatizzando idee strane con tutta gente che moriva arrostita da apparati >> ecm, e poi... vedendo che addirittura mi si erano posizionati un canale >> sotto (5Mhz, non 20) mi venne la brillante idea di rimediare un fucile a >> pallettoni e impallinargli le scatole sui tetti con dentro i wrt; io sono >> innocuo ma a qualcuno ogni tanto per fortuna passa all'azione). Dalla >> modularità (ie: la possibilità di cambiare radio se ve ne fosse bisogno) >> alla comodità. >> Tuttavia ve ne e' uno su tutti che non puo' essere ignorato e >> statisticamente fa passare tutti gli altri in secondo piano: il costo >> dell'impianto. >> Per mettere 2 apparati (uno minimale sul tetto e uno piu' complesso in >> casa) vuoi o non vuoi aggiungi un overhead di 20-30 euro (anche solo per le >> scatole e l'alimentatore). >> Per 10 anni la gente ha preferito modem in comodato d'uso dall'operatore; >> cioe' per non pagare 50 euro subito ed acquistare il proprio modem, finiva >> per pagarne 200 a forza di 2 euro a bolletta. >> >> >> >> Il giorno 04 gennaio 2013 16:45, Michele Pietravalle < >> [email protected]> ha scritto: >> >>> > Detto questo io sarei comunque favorevole a cercare un'alternativa al >>> firmware proprietario, magari spostando la logica di controllo del routing >>> su un altro apparato e lasciare > alle antenne il solo compito di parlare >>> tra di loro, ma questa è un'altra questione tra l'altro anche controversa... >>> >>> >>> **** >>> >>> Mi inserisco al volo in questa discussione;**** >>> >>> Per anni io ho fatto fare agli apparati sia la parte di interconnessione >>> radio che di routing; col tempo però è saltato fuori che per mille motivi >>> diversi non è la soluzione migliore..**** >>> >>> di pro c'è la semplicità di manutenzione e la compatibilità con vari >>> vendor;**** >>> >>> difattti il 90% dei problemi hardware si verifica sulla parte radio, e >>> non sulla parte di routing; di conseguenza un conto è cambiare solo >>> l'antenna esterna, configurare due parametri al volo e fine, un conto è >>> metter mano agli apparati di routing;**** >>> >>> tra l'altro in caso di upgrade di apparati radio (altri vendor, altri >>> bande di frequenza, etc) basta solo cambiare la parte radio lasciando >>> immutate le logiche di routing..**** >>> >>> ** ** >>> >>> ** ** >>> >>> *Da:* [email protected] [mailto: >>> [email protected]] *Per conto di *Lorenzo - Tulug >>> *Inviato:* venerdì 4 gennaio 2013 10:00 >>> *A:* [email protected] >>> *Oggetto:* Re: [Ninux-Wireless] Nuove policy SDK AirOS**** >>> >>> ** ** >>> >>> >>> >>> **** >>> >>> >>> http://www.ubnt.com/sdkrequest >>> >>> Ubiquiti SDK packages are now digitally signed and distributed >>> individually to customers upon request. In order to gain access to an >>> SDK, each customer must complete the following form. Upon completion, >>> Ubiquiti will review the form, and once approved, the customer will >>> receive an email with a digitally signed SDK package that is unique to >>> that customer. The SDK must be used only for that customer, and may >>> not be distributed or shared with others. >>> >>> SDK Usage Rules >>> >>> 1. The software may only be used with Ubiquiti hardware >>> 2. Copyright information may not be removed from the SDK >>> 3. The SDK may not be shared with other individuals/companies >>> 4. Any binary software should not be reverse-engineered or decompiled >>> _______________________________________________ >>> Wireless mailing list >>> [email protected] >>> http://ml.ninux.org/mailman/listinfo/wireless**** >>> >>> ** ** >>> >>> >>> Scusate, ma a me pare che se l'SDK viene preso a nome di una >>> associazione ed utilizzato solo all'interno di questa realtà non si va >>> contro il punto 3; inoltre non mi pare ci sia scritto che non è possibile >>> condividere il firmware compilato, ma solo l'sdk; quindi forse sarebbe >>> possibile condividere il solo firmware compilato. >>> Se comunque si trova una qualche forma associativa che ubiquiti può >>> riconoscere (anche fusolab), tutti i partecipanti possono tranquillamente >>> continuare a fare quel che viene fatto ora. >>> Discorso diverso per github, vero... bisogna creare un github interno a >>> ninux, ma anche quello non mi sembra una difficoltà insormontabile. >>> >>> Detto questo io sarei comunque favorevole a cercare un'alternativa al >>> firmware proprietario, magari spostando la logica di controllo del routing >>> su un altro apparato e lasciare alle antenne il solo compito di parlare tra >>> di loro, ma questa è un'altra questione tra l'altro anche controversa... >>> >>> Ciao a tutti >>> Lorenzo**** >>> >>> _______________________________________________ >>> Wireless mailing list >>> [email protected] >>> http://ml.ninux.org/mailman/listinfo/wireless >>> >>> >> >> _______________________________________________ >> Wireless mailing list >> [email protected] >> http://ml.ninux.org/mailman/listinfo/wireless >> >> > _______________________________________________ > Wireless mailing list > [email protected] > http://ml.ninux.org/mailman/listinfo/wireless > >
_______________________________________________ Wireless mailing list [email protected] http://ml.ninux.org/mailman/listinfo/wireless
