在大约4年又6个月之后，iPlacard公开了。其实Kaijia很早就应该公开了，因为在过去的几年陆陆续续近1400个提交，该实现的功能都已经实现了，现在还在Feature Request里面的除了允许主席收作业一项外大多都是在线聊天一类的请求，因此可以说是基本开发见顶了。原先的计划是当市场出现了同等水平的系统时就公开，现在看来没有熬到这天（蛤）。
iPlacard的代码可以访问 http://iplacard.com 或者直接GitHub仓库 https://github.com/fengkaijia/iplacard 获取。接下来的几天，Kaijia将在这篇文章里简单介绍几个iPlacard使用的注意事项。 阅读更多
昨天收到阿里云的通知，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与内地和香港的戴尔技术支持均有联系，但都无法测定该问题的原因（因为重复实验相当困难）。
Kaijia可以保证中文互联网上没有几个人在写自然语言处理的底层概念，这一领域的主要知识来源自然是学术论文及著作。写这个总结性文章的目的主要是作为笔记，同时Kaijia也希望可以帮助到正在GitHub上阅读文本蕴含识别系统代码的程序员。
文本蕴含系统（RTE）设计目的是识别文本T（Text，即在通常应用中的语料）与假设H（Hypnosis，通常即指提问）之间的关系。如果可以从文本T中推理出假设H，即代表文本T蕴含假设H。例如文本T为“Kaijia昨天购买了一台手机”，需要推定的假设H则可能是“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 jdk.internal.loader.ClassLoaders$AppClassLoader@16c0663d
不支持的系统类载入器 jdk.internal.loader.ClassLoaders$AppClassLoader@16c0663d
一般情况下如果对一个命令不熟悉，使用“–help”显示帮助信息在命令行程序中是约定俗成的传统。然而当传统碰到没有提供帮助信息的程序时就会出现尴尬。最麻烦的情况是，如果一个命令行程序设定的第一个参数是程序结果输出的文件时（虽然这样违背了管道原则），使用“–help”的结果就是生成了一个以连字符“-”开头的–help文件。
此时通常第一反映是删除这个文件
|
1 |
rm --help |
时却会发现此命令实际上显示了rm命令的帮助。同理以下命令均不能删除–help文件，它们在运行时都会被Shell转换成“rm –help”。
|
1 2 3 |
rm "--help" rm \-\-help rm * |
- 已经载入全部文章 -
近期评论