上文讲述了在国内环境下加速Discourse的部署过程。
Discourse官方并不建议在同一主机上部署多个站点，但也提供了方案：Running other websites on the same machine as Discourse。
按照官方的提供方案部署，通常可以正常将Discourse运行在standlone模式下，再通过Nginx反代访问。https的实现通过certbot也可以简单完成。
以下是nginx配置exsample:
工作一年总结
工作一年总结
虽然名为工作总结，但实际我应该总结的是这一年来个人的成长。
工作中成长虽然也算是一种。如果将当下的努力方向划分为短期、中期和长期目标的话。然而我过去一年的努力方向基本都在完成超短期内容的。事情是被推着走的。
正常的时间分配，对我而言，应该是泊松分布，主要时间分布在短期目标中，短期目标服从于长期目标，因此不会有太大的分歧。
记一例简单web业务性能瓶颈的改造过程
web项目通常由于需求紧，任务重，在上线初期，通常不会考虑太多架构性以及可靠性的问题。因此在业务稳定增长的过程中，大多都存在一个持续优化的过程。
这里记录一下前段时间，因某业务需要，对其持续优化的过程。
业务包括两个数据部分，一个负责实时数据上报的client，一个是负责数据接收以及实时数据展示的web系统。
优化目标有两个，一个是保证实时数据从收集到展示的延迟尽可能短，另一个是提高业务的可扩展性，保证业务的吞吐量不被一台服务器瓶颈所限制。
主要的操作包括静态资源加速，数据上报通道优化，服务器分布差异导致的延迟问题等。
web服务原始架构：
Client为安装在客户终端设备中的一个程序，浏览器为客户的其它带屏终端。Web Server为部署的服务器。
登录：
Client ==(认证信息)==> Web Server ==(返回服务URL)==> Client显示
授权通过后，Client开始收集数据并上传，客户通过Client显示的URL，在浏览器中加载完素材后，便有如下数据流。
XCode11下兼容arm64e的代码混淆编译器llvm11
对于ios程序，即使对binnary进行了加密，但启动之后加载到了memory中，还是存在一个解密的过程。 所以从源码以及编译器级别，对binary代码进行混淆是对抗安全攻击的最有效方法。
最新的apple处理器 a12 a13增加了arm64e架构，同时兼容arm64指令。
然而目前的最新的llvm-obfuscation 最高支持到llvm9，支持arm64e的llvm版本最低到llvm11。
去github上从apple的仓库中拉了llvm11的代码下来，给编译了一下，参考了现有的代码。重新实现了一个以支持arm64e。
在国内环境下安装Discourse
Discourse的版本升级与维护都是基于github来完成的，而Discourse本身又是基于ruby编写。
使用包括腾讯云的CVM、轻量服务器以及阿里云的ECS都存在国外网站访问慢的问题，主要是为了扶持国内git仓库做的限流操作。
在clone托管在github上的discourse时，可以通过将clone链接替换github.com为github.com.cnpmjs.org来加速对github的访问，比如：
将git clone https://github.com/discourse/discourse_docker.git 替换为 git clone https://github.com.cnpmjs.org/discourse/discourse_docker.git
除此之外，在运行./discourse-setup时，安装程序同样会在docker中安装一些额外的的项目，
比如：gem update，同样需要添加ruby的镜像。
可以通过修改配置文件来添加ruby镜像地址，主要涉及到的文件有
黑苹果实现iPhone/iPad快充功能
通常，iphon或iPad连接苹果电脑的USB口时，会使用快充功能，充电功率可以达到2.1A，在[关于本机->系统报告->USB-iPad]中可以看到可用电流为500mA，加上额外的操作电流1600mA，总共2.1A。
然而在MacOS 10.13中USB的电源管理部分，由之前的AppleBusPowerControllerUSB变成了AppleBusPowerController，对应的电源描述属性也有所变化，在tonymacx86.com上RehabMan大佬已经详细阐述了这个问题：
[Guide] USB power property injection for Sierra (and later)
也就是EC的问题。
然而，在我的k610d笔记本上，显示EC被正常识别，AppleBusPowerController也正常加载，USB接上iPad后，额外的所需电流只有900mA，起初没太在意，直到后来把网卡换成BCM943后，额外的所需电流变成了850mA，再到后来接上鼠标后， 额外的操作电流 (mA)变成了650mA，于是不能再忍了。
今天，查看主板USB供电部分，三个接口，左侧USB有一块1.5A限流芯片，右边一个USB3.0和一个USB2.0供电部分直接接到了S5态的19v转5v的DC-DC上，芯片型号为nb671，查看数据手册发现，该芯片持续电流可达6A，峰值电流可达9A，分出2A来充电也是绰绰有余了，不会造成沁硬件损伤。
由于重新修改SSDT-UIACaml中电源电流供应参数，将USB总电流供应由3200ma提升为4100ma，这样在有耗电设备增加时，也不会由于总供电量不足而减少iPad的快充供电。
参考https://www.tonymacx86.com/threads/cant-charge-ipad-using-usb-ports-el-capitan.230465/
阿里YunOS电视盒子中多遥控器兼容实现
Allwinner h3处理器，作为入门级4k解决方案，经过了四五年时间的打磨，使用定制化的系统，目前还是可以运行一些简单的直播类点播类应用，这两天闲着把家里两款H3的积灰了的盒子刷下固件，一个是迪优美特X16，一个是忆典S1，两者均使用的512MB内存，8GB存储的公版设计，使用了阿里的YunOS系统的机器，刷机时只能刷YunOS系统，否则刷机工具会提示 “烧写BOOT1分区失败” ，具体实现机制应该是有芯片设计配合实现。网上有大虾破解这限制，并制作了可以刷入的安卓固件。
h3的机器固件大多可以通刷，只是小部分gpio，包括遥控器等无法正常使用，这里分析其支持多遥控器的实现机制。
涉及到一个内核模块和一个交互程序以及一个按键映射表文件夹。分别是sunxi-ir-rx.ko和/system/bin/multi_ir以及/system/usr/keylayout/custom_ir_xxxx.kl，其源代码分别可在github上找到。
sunxi-ir-rx.ko负责接收红外数据并进行解析。具体外红数据格式为NEC协议，参考：https://www.cnblogs.com/zhugeanran/p/9334289.html
根据遥控器发出的设备地址码和命令码，结合/dev/下注册设备用于与multi_ir交互提供的按键映射，向系统input发送按键消息。通常，设备地址码与遥控器厂商相关，而命令码对应具体物理按键。
而multi_ir用于解析/system/usr/keylayout/中的custom_ir_xxxx.kl。并向sunxi-ir-rx.ko提供不同设备地址的命令码对应的系统按键。其中xxxx为设备地址码。
通过cat /proc/kmsg 可以实时查看sunxi-ir-rx.ko接收到的数据。
sunxi-ir-rx.ko中默认编译可以最大存储16个不同设备地址的映射，因此，文件夹中最多可能存在16个不同的设备地址映射文件。
一例多系统共存下的无陨迁移
四年前买的固态如今不知道什么原因，开机会有一定概率主板检测不到固态，需要多次重启才检测到。
然而最近这种情况概率越来越大了，于是决定换一块三星的，毕竟数据重要。现在的固态价格比起四年前大约降低了一倍多,可能是TLC技术的普及吧。
系统环境
原系统使用了128G固态msata接口＋500G机械，都使用的是GPT分区。原来加固态的时候就把机械上的Windows迁移到到固态，顺便把MBR分区转成了GPT，以兼容UEFI启动。
其中固态上为了三个分区，分别为（EFI分区，windows系统区，Ubuntu分区），机械硬盘5个分区，分别为（EFI分区，MacOS分区（原windows所在）以及D,E,F分区）
迁移环境
现在新换的固态为120G，原机械硬盘内容不动。需要将旧固态内容迁移到新固态。