Ivan Krstic wrote:
Higher transmit power, to be sure, but that doesn't help with supporting
many users in parallel on the scale that's needed here. In fact, even
amping up Tx power isn't an option in large-scale deployment, as it
decreases the MTBF unpredictably. There's a reason Linksys ships the
settings it ships.
Even without bumping the power, its still a good and effective solution.
That's one more thing that can be put into the "done" column.
I think you are grossly underestimating the logistics and management
costs of introducing separate hardware to serve as an AP, particularly
when it's a single point of failure. If the server/AP laptop dies, it
can be immediately replaced by another laptop. If a dedicated AP dies, a
new one needs to be ordered and shipped in, or the units need to be
distributed with spares, which doubles the cost outright.
On a purely economic basis, for the target price of a single OLPC, you can send
two access points at retail price. That means either leaving a spare in the
closet, or deploying it as a warm spare for extended coverage or better QOS.
What are the logistics and management costs of reprovisioning an OLPC as a
dedicated access point. Plus, I don't want to be the one ripping an OLPC out of
a kids hands for reprovisioning.
Even if you solved the above, the nightmare of security / update /
configuration management across a global deployment of dedicated APs
makes me cringe. It's doable, but very hard and to be avoided if at all
possible.
It's no more difficult to update it and probably has a far less likelihood of
needing it. There's not a lot of extra services running and fewer vectors for
attack. Sure its not impervious, nor is it even top notch, but its cost
effective and power efficient.
-Dean
--
olpc-software mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/olpc-software
