我的像素编辑器马上就可以上线steam了，商店和应用的审核都过了，就等一到时间就发布了。 这个应用做的我还是挺头大的，因为基本没有做过比较大的成品的桌面工具，而且还是跨平台的。里面涉及很多技术问题之前都没有接触过，走了很多弯路，折腾消耗了很长的时间。不过现在回头看，倒也还好，正常的学习折腾阶段。可能目前还有bug。 软件功能属于基本的不能再基本的了，后面还好持续更新迭代。目前只实现了颜料板，工具栏，图层等基本功能。动画的帧没有实现，后期实现这个功能，需要捋一下帧跟图层的关系。这个现在还是脑子空白状态，说实话这种情况实现软件，在设计上不太合理，后面加帧的功能有可能需要大改代码结构。还有很多有意思的功能，比如笔刷，还有一些性能优化要做。还有一些基本的，比如快捷键映射，保存目录等一系列小功能。 技术上，其实做这个的初衷有一部分是为了实现游戏框架，因为我发现这东西跟游戏逻辑一模一样。游戏引擎完全通用。所以实现上我直接从底层写的引擎的相关逻辑，没用当前的一些游戏引擎。比如，我选择直接从opengl开始撸，说到opengl，这个我也断断续续学了好几次了，在这个编辑器场景下，我opengl的方案修改了三次方案，只为性能更好，现在也觉得有优化空间，还有几个优化的想法，但是得需要性能测试。 ui用了imgui，挺不错的一个库。完全可以深度定制，属于我的引擎的一部分了。完全可以在之后的游戏或者软件开发里继续用。说到ui，让我想起了这个软件编程语言的选择，本来开始想的是用纯c撸，但是后来发现c的库太少了。比如ui这里觉得imgui很好，最终觉得用他。就决定直接改c++的项目，但是里面代码还是一部分c一部分c++, c++基本只用到namespace和调库使用，还有一个std 库。std库提供的基本数据结构，能减少c的很多手撸代码的情况，算是特别方便了。 然后后来渐渐的，由于软件场景的需要，使用的c++的面向对象的功能越来越多。包括后来考虑跨平台的问题，升级到c++17的标准，看了很多cppreference的文档。觉得c++17甚至20提供了很多的新语法，不比现代语言差。慢慢的基本写的时候，都用c++的库，包括写法。尽量不写c，发现c++确实有很多优点（虽然现在很多c++高级功能还没用到）。让我再一次放下对语言的偏见。 觉得c++兼容的c的标准，属于成也萧何败萧何了。但是如果能尽量保持c++的风格，就也很好了。 其他的三方库用的很少，刚加入了psdlog作为文件日志的选择，刚开始封装了一个标准输出的日志代码，现在也用不上了，约等于白写。 编辑器支持psd文件的读写，使用的三方库，但是我也改了一些问题，当时挺头疼的。 还有一个很大的问题是国际化的问题，刚开始考虑复杂了，以为要通过操作系统的语言去切换软件的语言，后来steam官方说的是通过steam控制的。我刚开始选择了gettext这种老牌库，然后就坑了。在mac上，locale完全设置不了，但是自己启动时没问题的，通过steam启动，locale失效，设置也不生效。而且windows上没问题。为了解决这个问题，我本来想上icu4c这个库，因为这个库还能解决编码的问题，一举两得。但是感觉要改的地方有点多，最后手撸了个代码，自己实现了一个gettext。至于编码兼容的问题，目前适用大部分情况就可以了。后面再改的时候还是要用icu这个库。 说到跨平台和编码问题，确实c++这种语言，跨平台的问题太大了，包括代码和第三方库的编译，gettext我刚开始在windows上折腾，用的源码编译静态库，后来用的系统自带的。现在也用不上了。因为用camke管理的代码编译，windows下我用的mingw编译环境，这个也折腾了好几天。开始装了win7，想多兼容几个系统版本。库的链接一直不通过，我以为是版本问题，升级了版本，发现直接不能用了。后来升级win8.1发现一样的问题。然后才知道是库链接配置的问题。 这个软件，看似功能不多，但是细节做起来还是挺复杂的。除了上面这些不了解工具链或者系统环境等导致的问题，还有直接技术实现的盲区。我印象最深的而且很简单的场景是：刚开始实现完画布和画笔的时候，感觉很开心，那时候觉得这个软件至少实现百分之七八十的功能了。其实现在看来可能百分之十。然后我用画笔乱画的时候，发现一个问题，鼠标移动过快的时候，其实系统能检测到的根本不是连续的点，我的想法有点想当然了。这就涉及一个问题，线的补齐，而且还需要怎么样补齐的合理，这个是关键。刚开始是懵逼的，后来查了很多资料，发现针对问题的想法还是很重要的。 最后还得感慨一下，我这个steam坑位本来是要留给游戏的，现在变成像素编辑器了。倒是可以为以后的开发做技术积累和框架提前实现。只是我一直在想的问题，现在不准备从底层撸框架实现游戏了。现在看看使用JavaScript写了，这个引擎暂时在这个游戏上用不到了。只是因为JavaScript的跨平台能力，小程序之类的，webgl/webassembly这种的还是目前不是主流，肯定折腾的东西太多。学技术可以折腾底层，搞项目还是快速的框架比较好。

本来以为很快安装完了，没想到安装过程中缺少不少文件，就决定再记录一下吧。 看系统软件库里版本太低，我就想直接源码编译安装。官网下载了2.4.3的版本。 编译命令：make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_SYSTEMD=1，这个是开启所有模式的编译方式，可看INSTALL文件配置 需要安装gcc:yum install gcc.x86_64 需要pcre:yum install pcre-devel.x86_64 需要openssl: yum install openssl.x86_64 openssl-devel.x86_64 需要安装lua，需要5.3版本以上，我从lua官网下载了5.4.3版本，可以直接make后，指定lua目录。make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_SYSTEMD=1 LUA_INC=/opt/source/lua-5.4.3/src/ LUA_LIB=/opt/source/lua-5.4.3/src/ 需要systemd-dev:yum install systemd-devel.x86_64 然后我现在记录才发现，就是参数指定的都需要额外安装的软件。 haproxy 配置文件 mkdir /etc/haproxy cp examples/option-http_proxy.cfg /etc/haproxy/haproxy.cfg 配置systemd cd admin/systemd/ make 会生成一个haproxy.service，我看就执行了替换bin目录 cp haproxy.service /usr/lib/systemd/system/ systemctl enable haproxy 直接start还是有问题，日志查看错误，需要改一下默认的配置文件和设置ulimit。 具体的详细配置还没看,只先瞟了一眼logging的配置。

安装没啥坑，提示还挺好，照着官方文档安装，基本都是回车：http://9p.io/wiki/plan9/installation_instructions/ 踩了三个坑， 一个是我选文件系统的时候选的fossil+venti ，硬盘选了2G，然后自动分区的时候可能把fossil分区的太少，复制文件的步骤太慢，而且各种报错，太慢了我感觉不堆，我又重启复制，报不同的错，最后才提示磁盘不足。我又重新开了个10g的硬盘，然后就可以了。 开始我还以为选择的镜像路线不对，然后发现可以ctrol+d退回到主菜单。 之后复制不到一分钟就复制完了，这个才是现代机器的速度嘛。然后重启后，输入用户名那里，提示的是none，我还以为进去创建文件，没想到的是需要输入默认用户名glenda，这个在安装文档里有，我后来报错才去看的文档。 放一张启动后的界面吧，感觉ui挺好看，就是还不成熟，vb中bug还挺多的。 我还看了点官方介绍，感觉备份那个思想现在Windows，mac应该都有，还有远程文件系统现在也都有，应该没啥新内容。待发掘

plan9可能有点古老了，看官网是80年代的产物，感觉那时候还没有操作系统垄断，dos可能也就刚出来，Windows还不知道在哪。今天想起来了，我又找了篇文章看了看plan9的介绍，反而激起了我对plan9的兴趣，感觉有些理念可以借鉴。被垄断后的思维就会狭隘，偏见，开开视野也是好的。 感觉好多古老的玩意还挺有意思的，比如老早之前知道，磁芯大战(core war or core wars)，细胞自动机（cellular automata）,《一种新科学》（A New Kind of Science）Stephen Wolfram。（这本书大体看了一下，有些思想我之前倒是想过，却没有这么深入细致的去研究） 记几个关键字，后边研究一下 装一下panl9操作系统，配置看一下那些特性，代码应该不会看。 Sam 和 Acme编辑器大体看看。 顺带知道一个操作系统Oberon，发现搜着看着东西越来越多了。 最近又看了篇文章，加深了对erlang的理解，之前还学过erlang语法，有时间再看看vm。 立了flag，不知道能不能看，发现要弄的东西不懂就难搞，不知道能不能坚持下来。下午有时间把plan9装一下。

准备玩点高级一点的东西了，xelatex看着不错，搜了一番，感觉texlive比较不错。也下载了Texmacs，那个只支持原生的latex，xelatex的导入导出不支持。现在已经懒得折腾东西，但是想想还是折腾折腾吧。直接apt安装的版本是2017的，感觉有点老，所以还是装个新的玩吧。 安装基本靠官网文档 首先下载一个安装工具，解压，执行perl install-tl 。 这里要看一下安装目录是否有权限，texlive的安装不需要root权限，但是默认安装目录是/usr/local/texlive/2020，最后一级目录是区分不同版本的，所以只要创建texlive目录，然后保证有权限就行了。 然后i开始安装，看着好像要下载四千多个文件，我使用的默认的镜像，速度还挺快的。主要看下载安装工具的时候速度就挺快。 还有gui版本的安装工具，包括安装完成后gui工具的使用，这个需要perl的tk库，sudo apt-get install perl-tk进行安装。比如：tlmgr -gui 更新系统使用命令：tlmgr update -all

Callgrind是valgrind的一个工具，能够分析程序运行效率，帮助找到程序瓶颈。 命令tool知道使用的valgrind的工具， valgrind --tool=callgrind ./a.out 运行完之后会生成一个callgrind.out.PID文件，然后执行下面命令进行分析 callgrind_annotate callgrind.out.PID 这个命令能够展示每个调用函数对应的执行指令的次数，展示已经排序，可以优先优化最顶部的函数。 cachegrind也是valgrind的一个工具，主要分析内存使用情况的，比如cpu cache的使用等。 简单使用命令： valgrind --tool=cachegrind ./a.out ==12810== ==12810== I refs: 13,413,053,205 ==12810== I1 misses: 3,851 ==12810== LLi misses: 3,552 ==12810== I1 miss rate: 0.00% ==12810== LLi miss rate: 0.00% ==12810== ==12810== D refs: 4,991,204,111 (3,140,940,594 rd + 1,850,263,517 wr) ==12810== D1 misses: 49,675,548 ( 38,504,518 rd + 11,171,030 wr) ==12810== LLd misses: 29,710,307 ( 19,488,129 rd + 10,222,178 wr) ==12810== D1 miss rate: 1.0% ( 1.2% + 0.6% ) ==12810== LLd miss rate: 0.6% ( 0.6% + 0.6% ) ==12810== ==12810== LL refs: 49,679,399 ( 38,508,369 rd + 11,171,030 wr) ==12810== LL misses: 29,713,859 ( 19,491,681 rd + 10,222,178 wr) ==12810== LL miss rate: 0.2% ( 0.1% + 0.6% ) 看着好像程序我的程序允许的比预期的缓存命中高很多，看官方文档说的。On a modern machine, an L1 miss will typically cost around 10 cycles, an LL miss can cost as much as 200 cycles, and a mispredicted branch costs in the region of 10 to 30 cycles. Detailed cache and branch profiling can be very useful for understanding how your program interacts with the machine and thus how to make it faster.现代机器，L1缓存丢失通常花费10个cpu周期，LL丢失花费200个周期，分支预测错误花费10-30个周期，所以这部分性能分析很重要啊。 LL指的是最后一级的cpu缓存，许多cpu架构可能有多级缓存，L1和LL具有代表性，所以只分析了这两种。 程序还是会生成一个cachegrind.out.PID文件，同样可以具体分析每个函数的内存使用情况 cg_annotate cachegrind.out.12810 这俩工具在官方手册上，每个一章进行介绍，具体也没研究，先初步了解一下

先说一下pyenv的安装方式，只有两步，第一步是将github项目clone到目录，第二步是添加环境变量。所以pyenv完全可以离线安装，比如操作系统版本一致的时候，直接把装好的pyenv环境和virtualenv环境复制到目标系统就可以了。然后添加一下环境变量。 我之前安装过pyenv了，更新pyenv进入pyenv目录后，执行git pull。 然后我复制了一份新的代码，改变环境变量，切换到新pyenv目录。然后卸载之前直接安装的python版本。pyenv uninstall 3.7.3 进入.pyenv_bak，mkdir cache.将源码包放到cache目录下。 进入.pyenv_bak/plugins/python-build/share/python-build目录，编辑3.7.3文件 #require_gcc prefer_openssl11 export PYTHON_BUILD_CONFIGURE_WITH_OPENSSL=1 install_package "openssl-1.1.0j" "https://www.openssl.org/source/old/1.1.0/openssl-1.1.0j.tar.gz#31bec6c203ce1a8e93d5994f4ed304c63ccf07676118b6634edded12ad1b3246" mac_openssl --if has_broken_mac_openssl install_package "readline-8.0" "https://ftpmirror.gnu.org/readline/readline-8.0.tar.gz#e339f51971478d369f8a053a330a190781acb9864cf4c541060f12078948e461" mac_readline --if has_broken_mac_readline if has_tar_xz_support; then install_package "Python-3.7.3" "https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tar.xz#da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318" ldflags_dirs standard verify_py37 copy_python_gdb ensurepip else install_package "Python-3.7.3" "https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz#d62e3015f2f89c970ac52343976b406694931742fbde2fed8d1ce8ebb4e1f8ff" ldflags_dirs standard verify_py37 copy_python_gdb ensurepip fi 改成 install_package "Python-3.7.3" "/root/.pyenv_bak/cache/Python-3.7.3.tar.xz" ldflags_dirs standard verify_py37 copy_python_gdb ensurepip 安装 pyenv install 3.7.3 安装完成后执行pyenv virtualenvwrapper，我发现需要重新安装这个插件，不知道为什么。我之前是安装了的，可能版本问题。 然后基本就可以了。virtualenv也是可以直接复制的，所以基本可以复制分发了。

rootkit hunter能检查一下系统是否被安装后门，听说很厉害。 去官网下载一个tar包，解压 安装 ./installer.sh --layout custom /opt/temp/rkhunter --install 这个是指定安装目录，日志都会打到/var/log/rkhunter.log 更新rootkit hunter的数据库 /opt/temp/rkhunter/bin/rkhunter --update 进行检查 /opt/temp/rkhunter/bin/rkhunter --checkall 然后查看结果 cat /var/log/rkhunter.log|grep "Warning\|Vulnerable" cat /var/log/rkhunter.log|grep -A 30 "System checks summary" 这个关键字可能不准确，具体看看总结，再细看检查的过程。

jenkins有好的方面，只有一个war包，目录基本兼容版本，迁移方便，可以在不同机器上编译。 今天打的包突然说代码没上去，然后查发现真没上去，啥都没改就出问题了。看jenkins打包日志没报错，checkout的分支也是对的。然后查workspace，svn log命令还执行不了，说版本不一致的啥问题，之前从一台机器迁移到另一台机器，两台机器的版本不一样就折腾了好久。但是也没再动，然后执行svn upgrade可以看log，一看没有新代码版本。卧槽急了一身汗，办公室也热。 然后跟同事一起分析，然后又看了一遍jenkins打包日志，在checkout代码完了之后，发现有个警告。。

WARNING: clock of the subversion server appears to be out of sync. This can result in inconsistent check out behavior.
同步了一下服务器时间就好了。网上说 在jenkins job的 svn地址后边加个 @HEAD 也行。
之后的项目等加上@head

supervisor的版本3.0a8的版本不支持stopasgroup的参数，感觉很痛苦。准备升级，debian的版本有点老，不支持apt-get升级。
然后准备用pip install安装新版本。



	

Stop service:

service supervisor stop


	
Backup current configuration:
mkdir ~/supervisor
cp -r /etc/supervisor ~/etc-supervisor
cp /etc/default/supervisor ~/supervisor/etc-default-supervisor
cp /etc/init.d/supervisor ~/supervisor/etc-init.d-supervisor


	
Remove current installation:
apt-get purge supervisor
rm -fr /etc/supervisor


	
Install new supervisor:
pip install supervisor


	
Restore configs:
cp ~/supervisor/etc-default-supervisor /etc/default/supervisor
cp ~/supervisor/etc-init.d-supervisor /etc/init.d/supervisor
cp -r ~/etc-supervisor /etc/supervisor
ln -s /etc/supervisor/supervisor.conf /etc/supervisor.conf #这一步新版本没必要


	
Start new supervisor:
service supervisor start


	
Verify:
supervisorctl


	
Set to run at startup:
update-rc.d supervisor defaults



这样做完有个问题是pip install的目录是/usr/local/bin/目录，需要修改/etc/init.d/supervisor的文件里的路径。