[Ninux-Wireless] R: Nuove policy SDK AirOS

Alessandro Gnagni enterprise.nx a gmail.com
Ven 11 Gen 2013 09:30:48 CET


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" <mfp a meganetwork.org>
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 <
> 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
>>
>>
>
> _______________________________________________
> 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/8882c402/attachment-0001.html>


Maggiori informazioni sulla lista Wireless