OpenWrt 是一个十分著名的嵌入式 Linux 发行版，被广泛使用在家庭路由器的魔改上。其前身是 Linksys 被迫开源的 WRT54G 固件。
最近几天买了一个 Intel J1900 CPU 的板子，集成了四张千兆网卡，于是就打算拿来跑 OpenWrt x86。但是呢，OpenWrt 官方放出的 x86_64 固件中使用的标准库是 uClibc，一个面向嵌入式 Linux 系统的小型的 C 标准库。可是手里的硬件确实正儿八经的 BayTrail CPU，使用 uClibc 未免感觉太憋屈了。不仅如此，绝大多数编译好的二进制软件都是使用 GNU C Library，同时 uClibc 没有提供对 glibc 的兼容，所以即便我是 x86 的 CPU，所有软件也都需要使用 OpenWrt 重新编译，很繁琐。于是，打算重新编译自己的 OpenWrt。
UglifyJS 是一个著名的 JavaScript 源码处理工具，可以用于压缩或是格式化 JavaScript 代码。同时他也是 JavaScript 编写，所以只要有 Node.js 就能很方便的使用。其项目主页：https://github.com/mishoo/UglifyJS
安装方法很简单， 假定你已经安装了 node 和 npm，你只需要执行以下命令即可完成：
npm install -g uglify-js
使用也是很简单的，我就举个压缩代码的例子吧，假设我们一个 script.js，需要进行压缩，可以执行以下命令：
uglifyjs script.js -o script.min.js
以上会对代码进行压缩，并保存为 script.min.js。值得注意的是这个压缩方法不会修改变量名，如果需要更彻底的压缩，则可以：
uglifyjs script.js -m -o script.min.js
实际效果的话，cnVintage 所使用的 flarum 中有一个 1.4MB 大小的 forum-7a006006.js，如果对其进行压缩能将大小缩减至 824K；如果对其使用更彻底的压缩，则能缩减至 611K，效果十分可观。
之前我们已经看到了如何利用 HTML 的 WebAudio API 播放一段自定义的音频，其实难度并不大，主要步骤就是创建音频上下文，创建缓冲区和音频源，之后在缓存区内暴力写入波形数据，就可以播放了。
有了这些功能，理论上我们是可以在浏览器里使用 JavaScript 解码任意的音频文件并播放的，然而实际上 JavaScript 本身算是个半残废语言，而且既然能用 HTMLAudio 标签来播放音频，为什么要自己解码呢（
不过话说回来，不是所有代码都是写了拿去用的，有的时候折腾折腾一些比较奇怪的东西也非常有趣。想到世界上有一个叫 WAV(audio/x-wave) 的音频格式，其结构听说也是非常的简单粗暴，在解码上基本没有什么复杂度。于是为什么不尝试着自己用 JavaScript 把 wav 音频通过音频上下文接口播放出来呢？
前天尝试了一波那个什么 MediaSourceExtension，结果发现那套API目前限制蛮大的，而且对我来说没什么帮助（audio/x-wav 完全不正常支持，audio/mpeg 也只能在 Chrome 上使用）于是只能放弃折腾了 QAQ
昨天突然想起之前写 nanoPlayer 的时候，使用了一个叫 Audio Context 的接口，nanoPlayer 用了这个 API 里的 createAnalyser 方法，来获得音频的频率数据，进而实现了一个频谱可视化功能。之前就注意到了这个接口中有个自定义 AudioBufferSource 的方法，可以指定若干 Float32Array 并交给浏览器播放，应该是蛮有意思的。
这里就实现一个可制定频率的正弦波音频吧，如果这个实现起来没有什么难度的话，就准备试试浏览器端解码 WAV 音频。
MediaSource 是 HTML5 中的一个实验性特性，用于给 `HTMLMediaElement` 对象提供数据源。这里的数据源通常是使用 `XMLHttpRequest` 获得的数据。在 XHR 取得数据后，我们可以使用 JavaScript 对数据进行一些操作，比如提取 ID3、修改封装类型等等。 某 bilibili 开源的 Flv.js 就是使用这个特性实现的在 HTML5 环境下播放 H264 + AAC 格式的 FLV 视频。
最近在写 `Nano Player` 的时候遇到了两个比较尴尬的问题：1、ID3 信息必须手动指定；2、网易云音乐上下载的 MP3 由于某些原因必须缓冲 2MB 才能播放（详见MP3缓冲2MB才开始播放的解决方法）。于是想到是不是可以用这个 MediaSource 来暴改 MP3 呢？我也不知道
不管怎样，要用这个 MSE 来解决问题，首先就是要用它来播放文件（如果获得的数据直接喂给 MSE 都不能播放那还讨论个什么鬼）
本站已经完全从 Linode 迁移到了 Azure！真的是快快快快（（
至于为什么要迁呢，主要是两个原因：第一是汇率问题，ConoHa 和 Linode 越发的涨价，不是很承受的起了。现在我手里 ConoHa 一台，配有一个额外的 IP 地址，每月基本要花到接近 100 块。Linode 是从淘宝商家上买的子账号，每月 73 CNY，合起每年要花这么多钱：
➜ ~ node -p '(100 + 73) * 12' 2076
相对的，一台基本型 A1 配置的 Azure 东京机房，从淘宝代购只需要 1530 CNY 就能搞定一年。
另一个原因是网络。Linode JP 和 ConoHa 对电信非常非常不友好，同时移动那儿也开始出现劣化的趋势，而 Azure 由于相对较高的门槛，尚未被玩坏，至少跑到 17000 Kbps 是没什么问题的。
上学期期末移动宽带质量不断劣化，我们宿舍被迫转向电信宽带。为了解决那个该死的防共享机制，我自费购买了一个坑爹的破解路由器，本质就是一个替换了 PPP 的 OpenWrt 路由器。选择购买而不是自己动手破解的主要原因是不想在这上面消耗太多精力，既然有现成的解决方案，那就掏钱解决了（
那个破解的路由器很渣，是个看起来就不像那种能拖宿舍里所有电子产品的破路由，所以我只将其作为拨号路由，而主要的 NAT 工作和 Access Point 仍然交给 WNDR 4300 来完成。电信的路由器 LAN IP: 192.168.43.1 并开启 DHCP，然后 WNDR 4300 直接将 WAN 接至任意一个 LAN 口，完成后顺手关掉了破解路由器的 WiFi
给隔壁 @ZephRay 开设的文复古电子产品交流社区定制的简易版网页，计划兼容到 IE3，可惜 IE4 才开始支持 UTF-8。功能基本上是完整了：登陆、发帖、回复、搜索、LaTeX 和图片的转码等等。
其实在现在做一个古董技术栈的网页并不困难，能用的技术直接把 Google 搜索的日期范围改到 2002 年前即可，IE 4 在当时已经能支持 JScript 和 CSS 还是很棒的了。
有几个比较麻烦的地方就是，首先 IE 4 不支持 PNG 和比较大的 JPG，需要在服务端将所有资源调整值最大不超过 `640×480` 的 JPEG。另一个就是 cnVintage 的 LaTeX 支持是通过 `KaTeX` 来实现的，而 IE 4 上这货肯定是跑不了，所以也需要在后端转化成 JPG。
最近几天无聊，又去上 LeetCode 探智商下限了（划掉
此类题整体较简单，而且在编码过程中不一定需要使用二分查找，用一些 hash based 的数据结构也是不错的选择。在 C++ 下借助 set, map 或是 binary_search + vector 都可以较为轻松的解决。
这几天一直折腾没啥意义的IPv6，首先是看到了 @蔓舞寻樱 dalao 的文章：利用代理隧道接入HE.net的IPv6网，就顺便在阿里云的学生优惠服务器上尝试部署了一下，拿到了前缀 2001:470:36:a90，前缀长度为 64 的 IPv6 地址池，就是这个速度实在是比较尴尬 _(:3」∠)_，从青岛阿里云到江苏教育网的 MTR 输出大致这样 （╯－＿－）╯╧╧
