Recently in cnangel手记 Category

在Linux系统中，一般有2大阵营，Debian和Redhat，其对应的桌面版本主要是Ubuntu和Fedora。

钉钉作为优秀的企业办公软件，当前也有Linux版本，由于Linux用户本身很少，故钉钉只发布了针对Ubuntu20.04的版本（com.alibabainc.dingtalk_7.1.0.31017_amd64.deb），对于Fedora系列无支持，那么应该如何支持Fedora系列呢？

putty版本：0.70

首先排除了fedora38上rsa私钥以及配置的问题，就剩下2个可能：

1，历史私钥不兼容；

2，Putty的问题；

用 docker 在 Dockerfile 上每次升级都很顺利，但突然之间，升级RPM包，报以下错误：

... signature hdr data: bad, no. ... of bytes(64372) out of range

网上查了一下，主要是由于RPM的一些兼容性问题导致（RPM签名的头超过了64KB），详情见"signature hdr data BAD" on trying to parse RPM with more than 64KB signature header。

如何解决的呢？

在Ubuntu20.04下编译zookeeper时，发现如下错误：

... Duplicate cpuset controllers detected. ... Picking /sys/fs/cgroup/cpuset ...

此错误是一个警告，，正常来说不应该引起编译失败，但因为zookeeper将javacc的输出作为了META-INF/MANIFEST.MF里面的version_info，导致这堆警告也被打入到MANIFEST.MF里面，这样jar包的检测机制认为这个jar包是有问题的。

解决方案有几种：

1，放宽jar包的检测机制：看上去后面运行这个jar包都会带着这个信息；

2，解决这个警告信息：看上去靠谱一些。

发现从代码层解决，需要升级新的openjdk，当前这个版本openjdk对容器化的"支持"不是很好，于是只能改日志等级，但我不想改变现在的代码和配置，采用如下命令行设置即可：

export JAVA_HOME=/usr/lib/jvm/java
export ANT_HOME=/usr/share/ant
export PATH=${ANT_HOME}/bin:${JAVA_HOME}/bin:${PATH}
export JAVA_TOOL_OPTIONS="-Xlog:disable -Xlog:all=warning:stderr:uptime,level,tags"

整个过程虽然有一些曲折，但最终解决了问题。

使用debmake创建debian模板时，发现出现如下错误：

FileNotFoundError: [Errno 2] No such file or directory: '//share/debmake/extra0export/compiler'

跟随python堆栈，了解到：

    # get prefix for install --user/ ,, --prefix/ ,, --home
    fullparent = os.path.dirname(sys.argv[0])
    if fullparent == '.':
        para['base_path'] = '..'
    else:
        para['base_path'] = os.path.dirname(fullparent)
  para = debmake.para.para(para)

出现了问题，修复方式也简单，因为base_path判断出现了bug，故强制在文件/usr/lib/python3/dist-packages/debmake/__init__.py中指定

para['base_path'] = '/usr'

搞定。此debmake版本是4.3.1，等官方修复之后再更新上去。

虽然在杭，但还是关注上海疫情，希望每个小伙伴们能够吃上新鲜的食材，以健康的身体坚持下去。

希望上海快点好起来。

今年的COVID-19比往年来得更猛烈一些，呆在上海，哪也去不了，储备了一周的各种方便食品，准备应对未来的日子。

Tensorflow的编译工程化做得不好，主要表现以下几个方面

1. 工程的依赖库默认从远程下载，而对于网络条件不好或中国地区用户，无法获得远程的依赖；且在repo.bzl中固化了mirror.tensorflow.org字样的代码，导致无法替换有效的镜像地址；
2. 工程编译速度非常慢（64Core大于10分钟），由于所有依赖都采用源代码进行编译，虽然编译工具bazel有缓存，但是仍然非常之慢；整个源代码编译在一个库里，好处是对于不同的操作系统，尤其是分布式集群，分发看似方便一些，不需要依赖安装，但同时带来了隐患，依赖缺乏有效管理，导致底层的依赖有问题，需要升级，是很难覆盖，且不知道tensorflow依赖它；
3. 工程依赖可视化管理比较差，上述已经提到，由于bazel的基因它只是一个编译工具，但它又想把依赖这件事情做好，具备很好的灵活性，有点像node和go库，但对于C/C++工程来说，每个库是远远比node和go库重一些，且很多是多层多次依赖，一般由操作系统来进行包的依赖管理，但bazel想自己做成一个王国，就有点勉强了。

回到tensorflow上来说，很现实的问题，系统的protobuf库使用的是高版本，而tensorflow 1.15.5版本内置的protobuf源码版本很低，如果tensorflow版本默认编译，低版本的protobuf符号会连接到tensorflow的库中，当我们应用需要protobuf高版本以及tensorflow库时，该应用的编译和连接没有问题，但运行时，会出现protobuf符号连接版本问题，那么这个时候需要解决版本冲突问题，当然问题不仅仅只有protobuf库，其他的库也是一样；故需要去指定系统环境的依赖库达到目的，由于bazel只有基本语法规范，但重要的还是tensorflow本身自己的编译工程需要去解决。
前面提到了tensorflow工程上的一些问题，对于系统提供的库，我们需要额外的cc_library和new_local_repository来代替new_http_archive，幸运的是，tensorflow考虑到了本地系统的依赖库，其配置在third_party/systemlibs中，syslibs_configure.bzl文件中有详细的依赖说明，故根据源文件查到环境变量TF_SYSTEM_LIBS来控制那些第三方依赖使用系统的库，故编译选项如下：

bazel build --action_env TF_SYSTEM_LIBS='boringssl,com_google_protobuf,grpc,zlib_archive,pcre,jsoncpp_git,curl,com_googlesource_code_re2,snappy,hwloc,lmdb,org_sqlite' --copt=-mavx2 --copt=-mfma --copt=-mavx512f //tensorflow/tools/lib_package:libtensorflow

即解决依赖库用系统已经编译好的库的问题

最近Fedora官方发布了Fedora 35，带来了一系列的改进：

• 全新体验GNOME 41
• 隐私保护DNS over TLS（DoT）
• Linux 5.14内核：针对ARM改进；GPU 优化； USB 4 的支持

一般奇数版本相对比较稳定，可以尝试一下哟

曾经去过新加坡的朋友回国都说新加坡如何如何的好，于是乎有机会也踏上了新加坡之旅。

新加坡是个发达国家，基本上以说英语和中文为主，所以不必担心自己的口语不好而感觉尴尬。