一些边界不断打破，是促进创新还是倒退？
Fedora Linux 41 默认为命令行包管理工具 DNF 的新主要版本。此版本更快、更小，并且需要更少的支持包。这消除了容器和内存受限系统对"microdnf"的需求----现在，可以跨容器、服务器、桌面和设备使用相同的 DNF。
Fedora Workstation 41 基于 GNOME 47。请阅读 Fedora Workstation 41 的新功能 了解详情。特别是对于命令行用户，Fedora41已将默认终端更改为 Ptyxis。它更轻量级，但也有一些不错的新功能。（如果用户需要 GNOME Terminal 提供的一些灵活性，它仍然存在。）
另外，目前还提供了几个重要的发布日错误修复和安全更新。如果用户从早期的 Fedora Linux 版本升级，将获得它们作为其中的一部分。对于新安装，请务必尽快检查并应用更新。
当打开以https开头的网页时，如果其图片、js或接口是http协议，正常浏览器是打不开该网页的。
当Clickhouse服务器强制关闭、异常断电、以及数据拷贝时等，导致Clickhouse数据损坏，服务无法启动，提示：
<Error> Application: DB::Exception: Suspiciously big size (4 parts, 1.05 GiB in total) of all broken parts to remove while maximum allowed broken parts size is 1.00 GiB. You can change the maximum value with merge tree setting 'max_suspicious_broken_parts_bytes' in <merge_tree> configuration section or in table settings in .sql file (don't forget to return setting back to default value): Cannot attach table `ads`.`xxx_tbl` from metadata file /var/lib/clickhouse/store/
需要在/etc/clickhouse-server/config.d配置中增加max_suspicious_broken_parts.xml文件，内容如下：
<?xml version="1.0"?>
<yandex>
<merge_tree>
<max_suspicious_broken_parts>1000</max_suspicious_broken_parts>
<max_suspicious_broken_parts_bytes>2147483648</max_suspicious_broken_parts_bytes>
</merge_tree>
</yandex>
然后启动Clickhouse即可：
systemctl start clickhouse-server.service
首先，确保宿主机安装好了GPU显卡驱动（这里GPU显卡驱动一般是指Nvidia显卡），通过命令：
nvidia-smi -l
可以检测是否正常。但启动docker时，发现找不到gpu驱动，命令如下：
docker run --name archlinux_for_cnangel -dit --gpus all --privileged=true --net=host -v home_cnangel:/home/cnangel -v /home/cnangel:/data -v /u:/u harbor.huhoo.net:4330/os/archlinux:latest /bin/bash
此时需要安装nvidia-docker2，它会自动带起2个重要的依赖（nvidia-container-toolkit和libnvidia-container-tools）安装：
dnf install nvidia-docker2 -y
然后重新运行上述docker run即可。
在Linux系统中，一般有2大阵营，Debian和Redhat，其对应的桌面版本主要是Ubuntu和Fedora。
钉钉作为优秀的企业办公软件，当前也有Linux版本，由于Linux用户本身很少，故钉钉只发布了针对Ubuntu20.04的版本（com.alibabainc.dingtalk_7.1.0.31017_amd64.deb），对于Fedora系列无支持，那么应该如何支持Fedora系列呢？
2003 年 11 月 6 日，Fedora 项目发布了 Fedora Core 1，而在二十年零一天后的今天，Fedora Linux 39 终于正式发布，这是为台式机、笔记本电脑、服务器、云、边缘计算设备以及您能想到的任何其他终端打造的完整社区操作系统。
一般证书上，对CRT和PEM证书没有特别做区分，故在nginx上部署了xxx.com_public.crt证书，发现curl 接口，出现如下错误：
curl 'https://xxx.com/api/campaign-names'
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
需要加上 -k 才能正确访问；若直接使用pem证书，则无需加上 -k 参数；
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。
如何解决的呢？
工厂类一般使用模板或宏的方式，如下列代码申明：
class ExpressionFactoryRegisterer
{
public:
ExpressionFactoryRegisterer(const std::string &name, const ExpressionFactoryPtr &factory)
{
GetExpressionTable()->RegisterExpressionFactory(name, factory);
}
};
代码注册如下：
REGISTER_EXPRESSION_FACTORY("log", std::make_shared<UnaryMathExpressionFactory<Func__log>>());
这样注册之后，一个简单的"反射"机制建立起来。但一般情况下，为了避免多重定义，会降代码注册的部分写到 .cc 文件中，但静态编译的时候， .cc 生成的 .o 文件，会通过 ar 工具打包成 .a 文件，此时 .a 文件直接去链接，静态区过程会滞后，导致 RegisterExpressionFactory 动作变成运行态执行。当程序真正执行时，初始化从静态区获取不到注册的类，导致空结果或指针。
正确的方式有2种：
动态编译：通过 -shared 生成 so 文件，然后链接；
.o 直接链接：将生成的 .o 文件直接链接，或通过 ar 工具解压 .a 文件，然后再链接 .o 文件；
