模逆元（modular multiplicative inverse）俗称模倒数，是指与原数的乘积和 1 同余的整数。即对于整数 $a$ 和 $n$：
上式中 x 就是 a 对于 n 的模逆元，$a$ 与 $n$ 互质时模倒数存在，否则不存在。 它的数学意义是模倒数存在时，除以一个数和乘以它的模倒数同余，可以把除法转换为乘法。 这对于计算大数（10 以上）组合问题非常有效，适用于 Sherlock and Permutations 和 Matrix Tracing 等问题。 这类问题的都可以转化为组合问题 ${n \choose m}$，由于它的值通常会很大，我们只关心它对某个大质数 M（比如 $1e9 + 7$）的模：
Linux 使用交换分区来休眠，首先冻结所有进程并申请足够的交换内存（位于磁盘），把当前内存都存进去。 然后下次启动时，initramfs 会直接加载上次休眠时的内存状态，跳过内核的 init 过程。 因此首先需要有足够大的交换分区或交换文件；再把内核指向到休眠的分区上；最后再配置 initramfs 让它加载休眠的内存文件。 官方文档请参考 Power_management/Suspend_and_hibernate#Hibernation， 本文细述如何休眠到交换文件，并对其中一些概念和细节进行了解释。
在本文讨论的范围内， 挂起（suspend）是指冻结当前的进程，保留它们的内存，并把几乎除了内存之外的设备都断电。 休眠（hibernate）是指把挂起后的内存写入磁盘并完全关机。 锁定（lock）则只是显示一个模态的全屏软件输入正确的密码才能退出。
最近发现我的 ArchLinux 每次解锁之后屏幕背光都会设置为最大，今晚终于有时间把它修复了。
写这篇文章介绍在 ArchLinux 下开机（Boot）和解锁（Resume）时，如何恢复此前的屏幕背光。
先解释背光控制的机制，再给如何入配置和调试。
本文以 MacBook Pro 2013 Late 为例（intel 显卡，xf86-video-intel 驱动）。
本文只解决背光恢复的问题，如果你的 Fn 功能键无法调整背光，请参考 在 MacBookPro 上安装 ArchLinux 中的“显示器/键盘背光”一节。
龙胆虎威 3 中的一个场景：在泉水旁有两个瓶子，容量分别是 5 加仑和 3 加仑。 Bruce 需要在 5 分钟内精确地得到 4 加仑水来停止定时器，差一盎司都会引起爆炸。 本文对这个问题进行推广，分别讨论有解的条件和解的构造两个问题，再给出判断是否有解的简单方法：能否被公约数整除。
如果目标水量 c 是 a 和 b 的线性组合就有解，否则无解。具体地：
c 是否是 a 和 b 的线性组合，取决于 c 能否被 gcd(a,b) 整除：
为方便讨论，本文所有线性组合都指整数线性组合，所有数字 x、y、m、n 都表示整数。
依赖注入 是编写可测试/复用代码的关键。 在 TypeScript 中所有对象、属性和方法都有类型，可以大幅简化人工标注的代码，这让很多人重新考虑在 JavaScript 中实现依赖注入。 比如 Angular2 以后的 DI 实现。 本文用来讨论 TypeScript 仍然无法解决哪些问题，以及相关技术可能存在的风险。
首先简单过一下基于 TypeScript 做依赖注入的步骤。 ES6 中提出了Reflect 用来访问和操作对象对象属性。 而 Reflect Metadata 提案 让 Reflect API 可以提供对类型的元数据进行操作的方法。 这样就可以在 tsc 编译时产出注册元数据的代码，在运行时就可以读到编译时的类型了，这一类型就提供了依赖注入的 Token。 运行时的注入器根据函数签名的类型拿到依赖关系，再根据类型对应的 Provider 来创建依赖树。
笔者在几个月前 切换到 Linux 下干活，使用 Xmodmap 交换掉 CapsLock 和 Ctrl。 但 Xmodmap 只能改键无法区分是哪个键盘硬件设备（偏偏 HHKB 的 Caps 本来就在左边），而且只在 X11 下好使（Virtual Console 下不起作用）。 于是近日研究了下 scancode 到 keycode 映射，通过 udev 匹配和配置特定的输入设备。 Harttle 的环境是 Macbook 下的 ArchLinux，下面的命令以此为例，但其他环境也应该类似。
注意：本文只讨论如何重新定义个别键的 keysym 的问题。更改键盘布局请参考 kbdmap，更改快捷键请使用 xbindkeys 或 i3 bindsym 或你的桌面系统配置。
AMD 是 RequireJS 给出的模块加载方案。 支持递归依赖解析、模块异步加载，夜兼容 CommonJS 可以在 Node.js 里用。 虽然目前已经不再流行，很多站点更倾向于编写 ES Modules 并直接 Webpack 打包， 但 AMD 是完整的，兼容性良好的，支持动态加载的模块化方案，在大型的、独立部署的、异构的项目中仍然有一席之地。 所以还是决定写一篇关于 AMD 最佳实践的文章，致敬老式的 Old School 的 Web 开发。
TL;DR