May 2014 Archives

Google Compute Engine

| 1 Comment | No TrackBacks

初步尝试了一下 Google Compute Engine(G社类似 Amazon EC2的产品,基于 Linux/KVM)。确认 FreeBSD 可用(在家里用qemu建一个image出来,装好,然后打包扔到 Google 的系统上,然后用这个包建一个image,再用image起个instance)。

几个比较显著的坑:

  • Google Cloud SDK假定bash位于/bin/bash。这个很容易patch。
  • 如果是在远程的 FreeBSD 系统上使用 Google Cloud SDK,它默认会起 links 作为浏览器。由于 links 不支持 JavaScript,因此会导致 Google Cloud API 授权失败。解决方法是关闭浏览器,然后通过 X forwarding 起一个 Chromium (我估计 Firefox 也没问题)来操作。
  • GCE的系统只支持GNU tar格式的文件,使用 FreeBSD 的 bsdtar 时必须指定用 gnutar 格式,或者用 GNU tar(bsdtar默认采用的是 pax interchange 格式,而 libarchive 目前并不支持 GNU tar 的 sparse 模式;具有讽刺意义的是 Tim 其实应该是在 Google? xz 支持未测,我觉得以只支持 GNU tar 的劲头应该是不支持 xz 的)。
  • 预设的防火墙规则基本只允许 ssh。
  • 系统内建 禁止任何发到标准SMTP端口 (25, 465, 587)的请求。可以理解禁止25,但是不太理解禁止465和587,意义何在?是为了推广 SendGrid 吗?
  • 初始的qemu镜像文件必须是10240MB。
  • 上传 qemu 打包之后,建立 image 后其实可以直接删除原包。

存到盘上的数据据说是加密的,不过个人认为扔到 Internet 上的数据基本就没有隐私可言了,有加密自然可以阻止一些泄密(例如如果一家创业公司想要保存一些患者信息,那么在 Google 本身不被黑掉且他们遵守一系列安全设计准则的前提下,他们至少不用担心由于硬盘坏掉,替换硬盘时这些数据被第三方厂商偶然得到),但基本上跟家里的门窗结实程度一样,你懂的。

实际测试,虚拟网络至少可以做到 100Mbps 跑满(对 Internet)。我认为对大部分普通应用而言应该是够用了。比较遗憾的是本地读写性能忘记测试了,等有时间再研究一下(看 这里 估计太快不了;可靠性方面,据说有内建冗余和校验和检查,不知道实际情况如何,个人感觉可靠性应该还不错)。

大通银行最近经常发一些其信用卡的 balance transfer 的活动。这种 offer 的特点是提供两张支票(一般来说有效期在2个月左右),通常提供18个月的免息期。

由于这种 offer 要收 2% 或 $5(以两者中较高者为准),所以我之前基本是直接碎掉的。今天和一位同学讨论了一下,发现似乎不是完全不存在合理价值,当然这次这份我还是要碎掉,但先把这个观点记下来,等以后有机会再做评估。

想要充分利用这种 offer,需要满足下面全部条件:

  1. 能够在18个月之内完全不使用这张信用卡。(使用条款规定,尽管 Balance Transfer 本身是18个月内 0% APR,算上 2% 的手续费不妨看做收 2 个点预付利息的小额贷款,也就是大约 1% APR,但此后新买的产品是按标准利率收取利息的。后者的利率通常在十几到二十几个百分点)。
    假如能封存这张卡18个月不用,好,这是一个 1% APR 的小额贷款,接着:
  2. 使用这些钱足以在18个月内产生至少2个点的税后收益。可能有同学说好,我去买 SPY,或者另类投资如 Lending Club,确实可以,但是这收益是没有保障的,而如果无法持有超过 1 年,又有可能按照短期资本利得来缴税,导致收益减少。
    购买能够免税的本州内城市债券基金可能可以。

我个人认为意义不太大:现金流不足的时候似乎应该采取更稳健的投资策略而不是继续举债?而如果现金流充足的话,为什么要举债投资呢?(毕竟信用卡的额度通常不会让一个人的现金流增加数倍,吧?)但是假如有很可靠的高收益投资机会,似乎并不是太坏的选择,只是在充分竞争的市场中出现这种投资机会应该不太常见就是了。

Intel RDSEED指令

| No Comments | No TrackBacks

今天看到 John Baldwin commit 的这个 r266391 增加了相关支持。

RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG,而 RDSEED 则是直接从真随机数发生器中获得输出(两者并不是直接使用真随机发生器的输出,这些输出是做过 AES-CBC-MAC 处理的,防止外界通过观测输出了解内部运行的细节),较慢,后者具备 multiplicative prediction resistance 特性。

具体细节可以参考 Intel® Digital Random Number Generator (DRNG) Software Implementation GuideThe Difference Between RDRAND and RDSEED

Intel 的后一份文档中建议实现 PRNG 时使用 RDSEED,不太清楚这样做是否会同时复位 RDRAND 的状态?假如不复位的话,这样做似乎也意义不太大?(PRNG 的实现者应该从更多的地方收集 entropy 而不是假定真随机发生器的输出可信)。

此外, DRNG 用的 AES-CBC-MAC 这个事情,我认为是一把双刃剑(虽然用比不用要好),因为这样一来便很难验证来自硬件的随机数是否具有某些特性了(此外我找到的文档也没有具体描述如何 AES-CBC-MAC 是如何使用的)。

由于送修 iPad 最终没有修好,因此店家给提供了一台二手的 iPad。作为不折腾就会死星人我觉得显然应该重刷一遍固件(卖家已经重新清空了数据),因此做了一次 DFU mode 固件更新。

具体做法是先把 iPad 接在 Macbook 上,同时按住 power 和 Home。等待大约10秒后屏幕變黑,此时按住 Home,等到 iTunes 上可以看到 Recovery 为止。

然后就是刷 iOS 和恢复数据了,此前过程中在网关听包未见明显异常。

Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.3