Esper 发布的文章

老版pytorch配新版编译器会出现一些奇怪的问题，在这里记录一下。

  1. Could not find libuv_tmp_LIBRARY using the following names: uv, libuv

libuv是做分布式异步io用的，咱们Windows单机用不到这个，通过设置环境变量USE_DISTRIBUTED=0跳过这一问题。

  1. algorithm(7417): error C2678: binary '*': no operator found which takes a left-hand operand of type 'const _BidIt' (or there is no acceptable conversion) [pytorch\build\caffe2\torch_cpu.vcxproj]

这个是mkl-dnn的问题，参考这个issue。

解决方法：升级mkl-dnn到1.7版本，或在aten/src/ATen/native/CompositeRandomAccessorCommon.h文件的第132行，在

reference operator*() {

处添加const关键字，修改为

reference operator*() const {

再重新执行编译指令即可。

  1. pytorch\caffe2\utils\math_gpu.cu(898): error : namespace "thrust" has no member "host_vector" [pytorch\build\caffe2\torch_cuda.vcxproj]

这个是CUDA的问题，恰好是11.4版本引入的，参考这个issue。

解决方法：在caffe2/utils/math_gpu.cu文件头部添加头文件引用：

#include <thrust/host_vector.h>

然后重新编译即可。

好耶，是红帽系的openEuler

dnf groupinstall -y "Development Tools"

# 下载源代码
git clone https://github.com/ceph/ceph
cd ceph
git checkout quincy-release
git submodule update --init --recursive

# 编译前准备
# openEuler 22.03的源里没有这两个python包，需要改为手动下载
sed -i -E 's/(.*asyncssh$)/#\1/gm' ceph.spec.in
sed -i -E 's/(.*natsort$)/#\1/gm' ceph.spec.in

# 官方还没有加openEuler的选项，但大概率是兼容的
sed -i -e 's/centos|fedora/centos|openEuler|fedora/g' install-deps.sh

./install-deps.sh

# 装完依赖之后再装dnf里没有的两个包
pip3 install asyncssh natsort

dnf install -y xmlsec1 doxygen ninja-build python3-sphinx
dnf install -y libibverbs-devel openldap-devel lz4-devel expat-devel lttng-ust-devel libbabeltrace-devel libatomic librabbitmq-devel librdkafka-devel java-1.8.0-openjdk-devel

# cmake配置
./do_cmake.sh -DCMAKE_BUILD_TYPE=RelWithDebInfo

# 开始编译
ninja

打RPM包的过程有点曲折，openEuler的维护者不知道在干些什么，去维护ceph.spec而不是ceph.spec.in，搞得我不知道版本更新的时候到底该对着谁的spec改了。。

这里就不理openEuler自己公布的spec文件了，用点取巧的方法，伪装成CentOS试试。

# 制作RPM源码包
./make_srpm.sh

# 展开RPM源码包用于安装
# 注意默认是解压到家目录下的，所以在ceph目录下执行完可能发现没任何变化，回家目录检查下肯定有rpmbuild文件夹了
rpm -i ceph-17.2.5-0.g98318ae89f1.src.rpm

# 安装编译依赖
dnf builddep -y --define 'rhel 7' --spec ~/rpmbuild/SPECS/ceph.spec

# 华子的像素级抄袭功底还是在的，包管理器名字都给你改喽
# 说实话还整个大小写混用让人挺不舒服的。。
sed -i -e 's/^BuildRequires:  redhat-rpm-config$/BuildRequires:  (redhat-rpm-config or openEuler-rpm-config)/gm' ~/rpmbuild/SPECS/ceph.spec
sed -i -E 'N;s/(^%if 0%\{\?rhel} == 8$)(\n%py_byte_compile.*)/\1 || 0%{?openEuler}\2/gm' ~/rpmbuild/SPECS/ceph.spec

# RPM编译
# openEuler上的cmake可执行文件是python脚本，然而很怪，一用rpmbuild，python就会掉PYTHONPATH，找不到cmake
# 伪装成rhel7，走centos的编译流程，但是又绕过软件包版本限制
PYTHONPATH=/usr/local/lib64/python3.9/site-packages rpmbuild -ba ~/rpmbuild/SPECS/ceph.spec --define 'rhel 7'

将编译的ceph RPM包作为repo提供给其他机器使用，参考：https://blog.csdn.net/DeamonXiao/article/details/120879577

dnf install -y createrepo
cd ~/rpmbuild/RPMS
createrepo .

然后另外单独起个后台进程，直接用http提供服务；这里用7000端口，根据需要可以自己调。

python3 -m http.server 7000

至此，一个repo就建立好了。

然后配置服务器使用这个源：

cat << EOF > /etc/yum.repos.d/Ceph-dev.repo
[ceph-dev]
name=Ceph Dev
baseurl=http://<ip-address>:7000/
enabled=1
gpgcheck=0
EOF

# 更新缓存，测试源是否添加成功
dnf makecache

苦逼兼职运维的第六年，已经无力吐槽Ubuntu了= =

症状：在nmtui里激活网卡，提示Could not activate connection: XXX because device is strictly unmanaged.

懒人解决方案：

sudo su -c 'echo ",except:type:ethernet" >> /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf'
sudo service network-manager restart

原因大致是Ubuntu的NetworkManager默认将以太网卡设置为了不管理模式，因而无法通过nmtui对以太网卡进行开关操作，即使配置了网络设置也不管用。而上面这段except则是反向操作，告诉NetworkManager不要不管理以太网卡。

咕果上翻了半天没找到合适的解决方案，感谢这位知乎网友：https://zhuanlan.zhihu.com/p/514966896

最近突然又想玩本地推流了，转来转去发现还是nginx做推流服务器比较舒服（开源且稍微熟悉一点），考虑到之前试过的别人编译的nginx 1.7.11.3 Gryphon过于老旧，而且卡顿严重，就打算自己编译一份。在这里简单记录一下编译流程。

仔细观察nginx官方提供的windows编译版，发现提供的还是32位程序，而在实际编译中也的确发现部分模块存在32位和64位混编导致失败的情况，因而最好用VS自带的x64_x86环境（Native Tools Command Prompt）启动cmd来尽可能避免编译出错。都什么年代了，还在用传统x86

set PATH=%PATH%;C:\msys64\usr\bin

pacman --noconfirm -S nasm

git clone https://github.com/nginx/nginx
git clone https://github.com/arut/nginx-rtmp-module

cd nginx
mkdir deps

cd deps
git clone https://github.com/PCRE2Project/pcre2
git clone https://github.com/madler/zlib
git clone https://github.com/openssl/openssl

cd ..

bash ./auto/configure --with-cc=cl --with-cpp=cl --with-cc-opt='/MP /wd4456' --with-pcre=deps/pcre2 --prefix= --sbin-path=nginx.exe --with-zlib=deps/zlib --with-openssl=deps/openssl --with-http_stub_status_module --add-module=../nginx-rtmp-module

nmake

编译完把nginx.exe复制到项目根目录下即可使用。

还是不要尝试nmake install了，不然会报出各种奇奇怪怪的错误= =

为了玩玩最近很火的AI作画Stable Diffusion，不得不想办法把我在古台上囤了N多的陈年老数据转移到机械大house上。按照常规操作，较为合理的方法是做出共享文件夹，然后用robocopy来更新具体数据。

然而直接卡在了第一步= =

右键文件夹一看，那个熟悉的“共享”选项卡不见了，接在“常规”后面的就是“安全”。。。

马上某度，发现也有许多人遇到这个问题，大致情况可以归类为两种：

一是注册表损坏，用于展示共享文件夹的COM组件配置丢失，这个需要通过手动设置HKEY_CLASSES_ROOT\Directory\shellex\PropertySheetHandlers\Sharing表项的值为{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}来修复；

二是系统组件运行异常，主要关注Security Accounts Manager和Server两个服务的运行状态，确保它们处于正常运行状态才能正常显示选项卡。

然而经过确认，我电脑上这两个地方都没问题，重启多次仍然不见问题解决。而后在绝望之中碰巧看到了另一篇博客，发现竟然是三哥干的好事。。。

实际上，在注册表里，除了有启用COM组件的配置之外，还有禁用的配置，比如HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked注册表项。打开一看，上面Sharing的COM CLSID{f81e9010-6ea4-11ce-a7ff-00aa003ca9f6}赫然躺在里面。

WTF？？我用的好好的，结果你把他给我禁用了？当场删除了对应的注册表子项，甚至不用重启，许久不见的共享选项卡就回到了属性界面。

忽然想起某乎上的吐槽，阿三工程师的特点之一就是做事自在，指不定哪天心情好就把哪个feature给你改了，但是只要你不问他，他就绝不会跟你提到这个事。

这咖喱味的系统我是一秒也不想多用了.jpg

参考：

  1. https://techcult.com/fix-sharing-tab-is-missing-in-folder-properties/
  2. https://weblog.west-wind.com/posts/2020/Apr/13/Missing-Sharing-Tab-in-Windows-Explorer
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. ...
  10. 53