小实验:扩展 PS4 的存储

PS4 到手之后游戏买买买,500G的磁盘换成了1TB也快用完了,但是买2TB的话就感觉很麻烦,一来是要全部重新迁移数据,二是换下来的1TB WD Black也没其他地方用,就很难受。

查了一圈后发现,PS4 在某次系统更新后提供了将 USB 存储格式化为扩展存储的功能,也就是说可以用 USB3.0 的移动硬盘来装游戏。可能是有偏见吧我一直觉得移动硬盘是非常不靠谱的东西,不过这个特性倒是一个不错的拓展存储的切入点。

要说扩展存储,如果是普通的 PC 上有这个需求,解决方法非常多,比如我可以建立一个 SMB 协议的共享,Windows 和 macOS 原生兼容,Linux 只需要加载 cifs.ko 即可;当然 NFS 来实现也没有任何问题;如果对加密有需求,或是需要一个裸磁盘,还可以用 iSCSI 来做到。可是 PS4 目前没有破解,以上方法都不可行。

于是就想,PS4 支持 USB 存储的扩展,我能不能将上面提到的一些方式通过 USB 暴露给 PS4 来实现呢?比如这样一个设备:它本身是一个 USB 从机,同时有一个 GbE 接口,可以千兆访问到局域网里的 iSCSI Target,然后通过一些魔法,将 iSCSI Target 拿到的磁盘设备直通到 USB,让 PS4 认为这是一个大容量的 USB 存储。

继续阅读小实验:扩展 PS4 的存储

网易云音乐 Linux 版高分屏问题解决方案

网易云音乐 Linux 版推出很久了,肯定已经有很多人反馈过 HiDPI 下不能正常工作的问题了,然而似乎网易生娃不养娃,版本号 1.0.0 从一开始就没有变过(

在网上搜索 HiDPI 下字太小难以阅读就能找到最简单的解决方案:添加参数 --force-device-scale-factor=2 就能让他强制两倍渲染。不过这个方法在我这儿(ArchLinux,KDE)上并不是什么好的解决方案:启动程序时,程序按照环境 DPI 创建了窗体,但是内容部分则依然使用原分辨率渲染,效果就是只有坐上 1/4 能正常显示内容,剩下的都是白色的空白。只要我的全局 DPI 不是 100%,这些空白就一直存在。

继续阅读网易云音乐 Linux 版高分屏问题解决方案

简易 Web Terminal 的实现

说起来也是有趣,本来是研究一下 WebSocket 准备给论坛/博客增加实时更新之类的特性,结果看着看着就脑洞大开搞了这么个玩意儿((

首先明确一下,这里说的 Web Terminal 是指再网页中实现的,类似于终端模拟器的玩意儿。举例的话应该是类似于 Linode 的 LiSH 和 Visual Studio Code 中内置的那个终端,而不是 ConoHa 提供的 VNC 式的终端(其实那玩意儿是个远程桌面了)。最终目标的效果就是和 Secure Shell 类似:打开一个网页,就能启动一个网页所在服务器的 shell,比如到处都有的 bash 或者非常强大的 zsh,然后就可以与这个终端进行交互式的操作,比如使用 vim 编辑文件,或者查阅 man 中的手册。

继续阅读简易 Web Terminal 的实现

单页应用下实现动态的脚本加载

之前在写自己的博客框架的时候遇到了一个问题:文章中的 script 标签没有任何作用,以 Vue 为 MVVM 框架举个例子:

继续阅读单页应用下实现动态的脚本加载

初音未来 歌姬计划 Future Tone 游戏视频

前几天拿到了游戏仅有的两个金杯中的一个:節奏遊戲大師[FS],发个视频庆祝一下(大雾

第一个是 Extreme 难度的こちら、幸福安心委员会です,洗脑曲,这个难度可以说是相当简单:

继续阅读初音未来 歌姬计划 Future Tone 游戏视频

[作业] AES-128-ECB 实现

首先呢这份代码是这学期选修课的大作业,前后也花了点心思,于是还是贴到这儿,顺便给博客除除草ww

作业的题目有两大类,一类是使用常见的对称/非对称加密算法(DES/AES/RC5/RSA/Blowfish/blabla)实现一个可用的加解密工具,另一个则是实现一个HASH程序,类似于 md5sum 或者是 sha256sum 这种。我选择了做 AES 主要是有几个原因:

  1. 老师说了,杂凑算法于加解密算法比较起来,实现难度低,因此基础成绩就会相对低一点(然而我觉得两个都蛮简单的啊)。
  2. 在上课之前就已经接触过 AES 这个算法了(归功于 Shadowsocks 啦),用了这么久的东西,也算是对它的实现比较感兴趣的(然而怎么想都知道自己写的破代码性能会被 OpenSSL 吊着打)。

当然按照老师的说法,简单的实现只是最基本的要求,所以我这里打算做三分实现,分别是 CPU 单线程,CPU 多线程和 GPGPU。其实这里面核心代码都是完全一样的,无非就是分组加密和密钥更新上有点区别,但是听起来就高大上了很多(没毛病)。

继续阅读[作业] AES-128-ECB 实现

[OpenWrt] 为 x86_64 平台编译自己的 OpenWrt

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。

继续阅读[OpenWrt] 为 x86_64 平台编译自己的 OpenWrt

使用 UglifyJS 压缩 JavaScript 文件

UglifyJS 是一个著名的 JavaScript 源码处理工具,可以用于压缩或是格式化 JavaScript 代码。同时他也是 JavaScript 编写,所以只要有 Node.js 就能很方便的使用。其项目主页:https://github.com/mishoo/UglifyJS

安装方法很简单, 假定你已经安装了 node 和 npm,你只需要执行以下命令即可完成:

使用也是很简单的,我就举个压缩代码的例子吧,假设我们一个 script.js,需要进行压缩,可以执行以下命令:

以上会对代码进行压缩,并保存为 script.min.js。值得注意的是这个压缩方法不会修改变量名,如果需要更彻底的压缩,则可以:

实际效果的话,cnVintage 所使用的 flarum 中有一个 1.4MB 大小的 forum-7a006006.js,如果对其进行压缩能将大小缩减至 824K;如果对其使用更彻底的压缩,则能缩减至 611K,效果十分可观。

[HTML] AudioContext 折腾笔记 02

之前我们已经看到了如何利用 HTML 的 WebAudio API 播放一段自定义的音频,其实难度并不大,主要步骤就是创建音频上下文,创建缓冲区和音频源,之后在缓存区内暴力写入波形数据,就可以播放了。

有了这些功能,理论上我们是可以在浏览器里使用 JavaScript 解码任意的音频文件并播放的,然而实际上 JavaScript 本身算是个半残废语言,而且既然能用 HTMLAudio 标签来播放音频,为什么要自己解码呢(

不过话说回来,不是所有代码都是写了拿去用的,有的时候折腾折腾一些比较奇怪的东西也非常有趣。想到世界上有一个叫 WAV(audio/x-wave) 的音频格式,其结构听说也是非常的简单粗暴,在解码上基本没有什么复杂度。于是为什么不尝试着自己用 JavaScript 把 wav 音频通过音频上下文接口播放出来呢?

继续阅读[HTML] AudioContext 折腾笔记 02

[HTML] AudioContext 折腾笔记 01

前天尝试了一波那个什么 MediaSourceExtension,结果发现那套API目前限制蛮大的,而且对我来说没什么帮助(audio/x-wav 完全不正常支持,audio/mpeg 也只能在 Chrome 上使用)于是只能放弃折腾了 QAQ

昨天突然想起之前写 nanoPlayer 的时候,使用了一个叫 Audio Context 的接口,nanoPlayer 用了这个 API 里的 createAnalyser 方法,来获得音频的频率数据,进而实现了一个频谱可视化功能。之前就注意到了这个接口中有个自定义 AudioBufferSource 的方法,可以指定若干 Float32Array 并交给浏览器播放,应该是蛮有意思的。

这里就实现一个可制定频率的正弦波音频吧,如果这个实现起来没有什么难度的话,就准备试试浏览器端解码 WAV 音频。

继续阅读[HTML] AudioContext 折腾笔记 01