我现在在曼哈顿市中心，通过酒店缓慢但昂贵的 Wi-Fi 连接上网。通常当我旅行时——至少在美国这里——我会避免使用糟糕的酒店连接，而是使用 AT&T 的蜂窝数据系统，通常是通过我的 iPhone 的“个人热点”。

但在这里不行，除非在凌晨时分，我猜是因为系统需求较低。但我不知道。也许你知道。如果知道，也许这些素材会激发解决问题的热情

PING google.com (74.125.225.115): 56 data bytes
64 bytes from 74.125.225.115: icmp_seq=0 ttl=51 time=101.064 ms
64 bytes from 74.125.225.115: icmp_seq=1 ttl=51 time=92.423 ms
Request timeout for icmp_seq 2
(省略)
Request timeout for icmp_seq 32
64 bytes from 74.125.225.115: icmp_seq=2 ttl=51 time=31309.253 ms
64 bytes from 74.125.225.115: icmp_seq=3 ttl=51 time=30364.809 ms
64 bytes from 74.125.225.115: icmp_seq=5 ttl=51 time=28366.889 ms
64 bytes from 74.125.225.115: icmp_seq=7 ttl=51 time=26370.460 ms
64 bytes from 74.125.225.115: icmp_seq=10 ttl=51 time=23369.719 ms
64 bytes from 74.125.225.115: icmp_seq=12 ttl=51 time=21384.230 ms
64 bytes from 74.125.225.115: icmp_seq=14 ttl=51 time=19385.376 ms
64 bytes from 74.125.225.115: icmp_seq=4 ttl=51 time=29390.279 ms
64 bytes from 74.125.225.115: icmp_seq=6 ttl=51 time=27393.178 ms
64 bytes from 74.125.225.115: icmp_seq=9 ttl=51 time=24401.894 ms
64 bytes from 74.125.225.115: icmp_seq=11 ttl=51 time=22405.324 ms
64 bytes from 74.125.225.115: icmp_seq=13 ttl=51 time=20404.648 ms
64 bytes from 74.125.225.115: icmp_seq=15 ttl=51 time=18448.794 ms
64 bytes from 74.125.225.115: icmp_seq=34 ttl=51 time=453.465 ms
Request timeout for icmp_seq 47
(省略)
Request timeout for icmp_seq 58
64 bytes from 74.125.225.115: icmp_seq=35 ttl=51 time=24054.439 ms
Request timeout for icmp_seq 60
(省略)
Request timeout for icmp_seq 87
^C
--- google.com ping 统计 ---
89 个数据包已发送，17 个数据包已接收，丢包率 80.9%
往返行程 最小/平均/最大/标准差 = 92.423/20452.720/31309.253/10051.146 毫秒

对于这些信息，我们可以有两种处理方式。一种是批评 AT&T，或者批评我使用 AT&T（以及使用 iPhone...顺便说一句，我也有 Android）——或者批评尝试通过像蜂窝数据系统这样商业化和粗糙的东西来做任何严肃的事情是徒劳的。另一种是作为技术人员，帮助 AT&T 解决它显然存在的问题。如果我们能做到的话。

这就是这里的吸引力所在。到底哪里出错了？容量配置不足？缓冲区膨胀？还是其他原因？

我想通过这次实践探讨另一个问题，那就是公司向客户/用户方面寻求帮助的开放性。像 AT&T 这样的公司并没有为此做好准备。它们的组织结构是为了从内部自我修复。这排除的外部帮助来源比它包含的要多，特别是当问题是技术性的，并且外部有技术人员拥有视角和专业知识，并且可以提供有用的帮助时。

对公司向真正的外部帮助敞开大门的前景持怀疑态度很容易。尝试打破它们的封闭状态更难。但这正是我在这种情况下追求的目标。

我们这里有很多技术读者。很多读者都有手机。可能不止少数人遇到了与我的手机在这里遇到的相同问题（而且不仅仅是 AT&T 的问题）。为什么不伸出援手呢？

这里还有另一个需要考虑的因素：现在还处于早期阶段。我们几乎还没有开始构建 Bob Frankston 所谓的“环境连接”的基础设施。很有可能，一旦我们拥有环境连接，蜂窝电话技术将不再是我们大多数人在堆栈的较低层使用的技术。但是，如果我们帮助解决我们今天拥有的系统中的缺陷，并且蜂窝连接上的移动数据就是其中一个系统，那么我们就能更快地实现环境连接（以及更近期的里程碑），我认为。