[Ninux-Wireless] R: Nuove policy SDK AirOS

Michele Favara Pedarsi mfp a meganetwork.org
Ven 11 Gen 2013 06:09:31 CET


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
<m.pietravalle a 4isp.it>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:* wireless-bounces a ml.ninux.org [mailto:wireless-bounces a ml.ninux.org]
> *Per conto di *Lorenzo - Tulug
> *Inviato:* venerdì 4 gennaio 2013 10:00
> *A:* wireless a ml.ninux.org
> *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
> Wireless a ml.ninux.org
> 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
> Wireless a ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/wireless
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/wireless/attachments/20130111/2b798c75/attachment-0001.html>


Maggiori informazioni sulla lista Wireless