<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>Il 13/05/2014 01:51, Vincenzo
Pirrone ha scritto:</tt><tt><br>
</tt></div>
<blockquote cite="mid:53715E71.5070809@gmail.com" type="cite">
<pre wrap="">Sarà un problema di trunk? Sarà l'841? boh
</pre>
</blockquote>
<br>
In realtà non credo che trunk abbia problemi, a parte un footprint
di 400-500 KiB superiore rispetto ad AA (che comunque è la stessa
cosa che è successa tra backfire e attitude).<br>
<br>
Io sto sperimentando con trunk su 841 v8. Non credo sia rilevante
però, tutti i target da 4MiB si equivalgono.<br>
Si tratta del caso peggiore, con Luci e BB, footprint alto.<br>
Nella mia build "finale" sono inclusi<br>
<br>
<meta name="generator" content="Sheets">
- luci<br>
- luci-ssl<br>
- olsr<br>
- olsrd-mod-txtinfo<br>
- olsrd-mod-mdns<br>
- olsrd-mod-nameservice<br>
- olsrd-mod-dyngw<br>
- olsrd-mod-arprefresh<br>
- luci-app-olsr<br>
- kmod-ipv6<br>
- ip6tables + kmod-ip6tables<br>
- kmod-gre; kmod-gre6
<style type="text/css"><!--td {border: 1px solid #ccc;}br {mso-data-placement:same-cell;}--></style><br>
- tc<br>
<br>
Il risultato è 3.5 MiB di sysupgrade, flashato rimangono 168KiB.<br>
Quanto sopra se non sbaglio è largamente condiviso da tutti, a parte
GRE e tc.<br>
Prima di proseguire e trarre il massimo da quei 168 vorrei capire le
posizioni su GRE e QoS. Le mie:<br>
<br>
* GRE: è l'unico modo per offrire una feature IMO fondamentale, il
tunnelling, senza strippare luci e senza essere alla mercé dei
footprint futuri di Openwrt (mettiamo che ci facciamo stare tinc per
miracolo su BB, che facciamo quando esce Openwrt "CC" e non ci sta
più, cacciamo una features su cui la community fa ormai
affidamento?). Occupa pochissimo. Certo, ha degli shortcomings in
sicurezza ma su questo possiamo fare informazione e divulgazione
alla community. E magari mitigare (firewalling?).<br>
<br>
* TC: la presenza di un QoS mi piace, può invogliare i ninuxers ad
annunciare HNA 0.0.0.0 sapendo di poter darne efficacemente una
fetta senza compromettere la propria usabilità. Tuttavia ci sta TC e
basta, e non possiamo onestamente sperare che senza un wrapper o una
gui la feature venga sfruttata anche da chi vorrebbe. Purtroppo,
QoS-Scripts tira giù troppe estensioni di netfilter e GUI per tc
puro OpenWRT non ne ha. Siamo nella terra di nessuno, dove la
feature c'è ma non è sfruttabile davvero.<br>
Per ora la considero ammessa con riserva, ma considerando i
candidati che spingono per entrare (ip) e soprattutto il fatto che
non sappiamo ancora come deployeremo IPv6 e che (se) altri pacchetti
serviranno, TC per quanto mi riguarda sarà il primo a far spazio.<br>
<br>
Ora io scalo una marcia e lavoro al caso immediatamente inferiore,
target di 4 MiB + Luci, ma su AA 12.09.1. Parto da quei stessi
pacchetti e vedo quanto il footprint più basso ci regala.<br>
A seconda di quanto ci rivela, possiamo pensare una cosa per
sincronizzare AA e BB sul target da 4 MiB: su AA ci sarà Luci, su BB
solo cli. Mi sembra una cosa molto più manutenibile e scalabile che
offrire molte, molte funzionalità presenti solo su una versione ma
non sulla *successiva*.<br>
<br>
Vi lascio con una immagine per tirarvi su il morale :)<br>
<br>
<a class="moz-txt-link-freetext" href="http://i.imgur.com/p7U1RFK.png">http://i.imgur.com/p7U1RFK.png</a><br>
<br>
Stefanauss.<br>
</body>
</html>