昨天收到阿里云的通知，Kaijia一台青岛机房2年半前创建的阿里云实例（可用区B）需要迁移到新的物理机上（即从两三年前最早的系列I升级到现在的系列III）。毕竟是性能升级，于是Kaijia很高兴得预约了吃螃蟹，结果升级完成了之后，实例就无法再次连接上了。
Kaijia从管理面板终端登录，发现执行ifconfig并无原有的eth0和eth1，而手动激活网卡时则会出现错误：
# ifup -v eth0
cannot find device “eth0”
Dell XPS 13系列自9343以来的设计堪称经典，但毕竟是超薄机型，对电路设计的要求等原因导致一直以来XPS 13都伴有着各种稀奇古怪的硬件问题。其中之一便是Kaijia使用一年以来经常碰到的触摸板假死/光标漂移问题。重复此问题需要满足几个条件：1、XPS未充电；2、XPS未放平（例如放在教室的折叠式桌板上）；3、XPS使用超过5分钟（且略烫）；4、手指有汗渍。此时触摸板非常容易偶发假死——手指在移动触摸板上移动但光标却无响应，换用其他手指或按下触摸板左键移动时则可正常响应——或光标在移动过程中上下漂移。Kaijia与内地和香港的戴尔技术支持均有联系，但都无法测定该问题的原因（因为重复实验相当困难）。
Ubuntu长期支持版的HWE（硬件加强）是快速升级Linux内核的便捷方法，目前Ubuntu 16.04的HWE提供了4.8（linux-generic-hwe-16.04）和4.10（linux-generic-hwe-16.04-edge）两个内核版本。
通常为了采用新的或改进的技术，例如TCP_BBR和更新的KVM等等，Kaijia会将服务器升级到最新的HWE。然而HWE内核通常也会带来一个衍生问题——仅Linux内核获得了升级，动态内核模块（DKMS）等组件在APT仓库中均停留在原先的版本上，因此可能会产生不兼容无法通过编译的问题。这次Kaijia遇到的Xtables-addons DKMS无法通过编译就是在升级到HWE内核后产生的：
——————————
Deleting module version: 2.10
completely from the DKMS tree.
——————————
Done.
Loading new xtables-addons-2.10 DKMS files…
Building only for 4.10.0-21-generic
Building initial module for 4.10.0-21-generic
Error! Build of xt_ACCOUNT.ko failed for: 4.10.0-21-generic (x86_64)
Consult the make.log in the build directory
/var/lib/dkms/xtables-addons/2.10/build/ for more information.
大量网络文件协议需要利用FUSE（用户空间文件系统）挂载成本地目录，例如SSHFS、CurlFtpFS、EncFS等。而此挂载过程随着IO和网络请求的产生必然会形成缓存，其中包括FUSE协议本身使用的缓存以及内核缓存。在物理机和硬件虚拟化（Hypervisor）环境下，这些缓存会在内存中体现为cache，内存耗尽时将会自动被挤出，并不会对系统产生影响。但是，在LXC等容器环境下，受限于请求控制，这些缓存并无法被标记为cache，而是标记为正在使用的实际内存，虽然最终内存耗尽时仍会部分被挤出，但对于运维等服务器管理工作来说，会造成不必要的误会。
对于有强迫症的人通常会对翻译错误无法忍耐，尤其是，老外翻译的中文。碰到这种情况时，Kaijia经常会联系软件商更正翻译错误。一般情况下个人开发者都会非常友好得接受Kaijia的翻译建议，然而总有几家中型软件商，通常没有大中华区市场，会拒绝Kaijia的建议，理由基本上是：我们外包的翻译虽然母语不是中文，但他们可是专业翻译。这种情况下，虽然无力吐槽但毕竟是开源软件，Kaijia会选择维护一个自有的译本更新部分错到离谱的翻译，然后重新编译软件。对于只需要修改几处的情况非常合适，每次软件发布更新，只需要重新替换几处译文便可重新编译，但对于大型软件涉及几十或者上百处更正的情况，每次更新时简单的人工替换显然不合适。通常情况下需要将Kaijia现有维护的译文与新版本自带的译文合并。此处合并需要满足两个需求：
在Gettext环境下，可以通过msgcat或msgmerge（互有区别）两个命令实现这个操作。这两个命令均为Gettext自带的工具，Linux发行版中安装Gettext时会默认安装。语法分别为： 阅读更多
好久一段时间不用SmartGit，上一次使用应该还是在Ubuntu 14.04上（之后IntelliJ IDEA和命令行几乎包揽了日常Git工作），这次Kaijia重新在Ubuntu 16.04系统上安装SmartGit时却遇到了无法启动的窘境。按照往常安装顺序将安装包解压运行之后，Unity启动栏上出现了SmartGit的图标，但之后立即消失了，并且没有弹出载入界面。
Kaijia在命令行中运行了bin/smartgit.sh文件，获得了以下提示：
Unsupported system classloader [email protected]
不支持的系统类载入器 [email protected]
一般情况下如果对一个命令不熟悉，使用“–help”显示帮助信息在命令行程序中是约定俗成的传统。然而当传统碰到没有提供帮助信息的程序时就会出现尴尬。最麻烦的情况是，如果一个命令行程序设定的第一个参数是程序结果输出的文件时（虽然这样违背了管道原则），使用“–help”的结果就是生成了一个以连字符“-”开头的–help文件。
此时通常第一反映是删除这个文件
|
1 |
rm --help |
时却会发现此命令实际上显示了rm命令的帮助。同理以下命令均不能删除–help文件，它们在运行时都会被Shell转换成“rm –help”。
|
1 2 3 |
rm "--help" rm \-\-help rm * |
Laptop Mode Tools是笔记本运行Linux时的常用标配工具，在汉语Linux社区常被称为“省电模式”，其原理就是通过给硬盘和CPU降速、自动休眠部分USB等各种方式千方百计降低笔记本运行Linux的功耗。
此工具由于其大幅提升Linux笔记本的续航时间而大受欢迎，然而它也经常有误伤，比如Kaijia的USB鼠标则是每次中枪。鼠标在启动进入GRUB界面时一切正常，之后当Laptop Mode Tools启动（enabled）后，无论是否接入电源/即省电模式是否激活（[not] active），鼠标都会自动断电休眠，每次都需要重新拔插后才可正常使用。
这个问题由来已久，中文社区也有大量的帖子和博文给出了解决方案。其中的核心思想是鼠标自动休眠是由Laptop Mode Tools工具的usb-autosuspend模块控制的，因此解决方案分两种：
- 已经载入全部文章 -
近期评论