老鱼平常经常会纪录一些笔记，其中一部分放在这里，希望对大家有所帮助。
今天搞明白了，为啥 dos 有个 A20 地址线，以及 DOS 所谓高位内存的技术了。原因出在那个段地址的计算上面，经常看到的段的计算方式，实际上不止可以访问到 1M 的内存，而是 1M 再多一些： 0xffff * 16 + 0xffff 可以访问到比 1M 高一点的 64k 内存。实际上不是 64k，而是 64k-16 字节。因为 ffff:0010 就是 1M 比较早的 DOS 程序，会利用 8086 的 bug，访问这段内存实际上是访问 0000:0000 这一段内存。后来 80286 出现，这个 bug 就失效了。 由此引申出 DOS 内存的几个概念。
Qt 6.3 重镑发布了新的 Qt Quick 编译器，号称性能至少有 30% 的提升，能够以接近 native 的速度运行 Qt Quick 程序。我觉得这是一个在工程上相当漂亮的技术，所以在此做了一个介绍。 其基本原理是改造 QML 语言，现在已经不是一个纯粹的 JavaScript 了，而是类似于 TypeScript，能够在变量声明、函数参数、函数返回值添加类型标志。有了类型以后，Qt 提供了两个部件也就顺理成章了: QML 脚本编译器qmlsc，负责把 JavaScript 脚本编译成 C++ 代码。 QML 类型编译器qmltc，负责把 QML 文档编译成 C++ 代码。 脚本编译器仍然不能完整翻译动态的 JavaScript 语法，但是能够准确地识别其中 QML 类型的属性访问，算术指令和 ifelse 判断，循环等等结构并翻译成 C++. 其它的仍然被翻译成字节码供 QML 虚拟机解释执行或者 JIT. 目前脚本编译器暂时只对 Qt Device Creation 商业用户开放。普通的开源用户，仍然只能使用自 Qt 5.8 以来的qmlgencache. 而类型编译器，则能够比较准确地把 QML 文档翻译成 C++ 代码，目前这个 QML 类型编译器已经向所有 Qt 6.3 用户开放了。
在 openSUSE Leap 15.3 底下跨平台编译 mingw64 程序，只要安装跨平台编译的安装包就行了： sudo zypper in mingw64-cross-gcc-c++ 接下来我们就来操作一下: // main.c #include <stdio.h> void main() { printf("hello, world!\n"); } 然后运行: $ x86_64-w64-mingw32-gcc -o test003.exe main.c $ wine ./test003.exe 可以看到打印出结果。
使用 Python 开发的朋友们应该都知道 virtualenv 和 venv 创建虚拟环境了吧。 使用虚拟环境不会破坏 Python 的系统环境，也方便了布署，实在是非常好的编程实践。比较常用的几个 IDE，比如 PyCharm 和 Visual Studio 对虚拟环境的支持都不错。创建工程的时候可以选择一起创建虚拟环境，或者在 IDE 里面点几下搞定。实在非常方便。终端下则是 .env/bin/activate 激活。 不过虚拟环境要怎么布署呢。还有什么小技巧大家不知道的呢。本文跟大家分享使用 activate_this.py 和检测 python 解释器的两种小技巧。
Qt 为 windows 提供了一个在线安装包，以及一个巨大的离线安装包。使用在线安装包能够自由选择 Qt 版本。使用离线安装包可以在不需要网络地方或者在多台机器上使用。 但是两个安装器安装的 Qt 容量都太过于巨大了，包含了所有的 Qt 模块以及它们的 debug 信息。如果我们只使用 C++ 以及 QtWidgets 做 Qt 开发，就没必要安装那么多的组件，浪费空间。这时候可以考虑自己编译一下 Qt
在线系统经常需要存储用户名和密码等认证信息，以便在用户登录的时候认证密码。但存储密码的时候其实有很多学问。在原始的互联网时期，使用明文存储密码。在经历了多次严重的泄露事件以后，没过几年即使是最蠢的程序员都知道得在存储前使用 MD5 哈希一下。 现在我们已经知道使用 MD5 存储也不靠谱了。拿着 MD5 哈希后后的一串代码放到搜索引擎里面搜一下（彩虹表攻击），密码就出来了。对抗这种攻击的办法是给密码加盐，就是每次哈希前都带上一段随机字符串，并且和密码一起存储起来，这大大提高了破解的难度，即使你使用的是 123456 这么简单的密码，也不容易一眼就看出来了。
跟我打交道过的人都知道我一直在唱衰桌面端 Qt，但是又一直在推荐大家使用 Qt 作为服务端开发的标准库。服务端开发除了完成功能之外，还需要考虑到服务端运维。一般希望布署的程序越简单越好，只好不依赖于特定的系统，一个文件复制到服务端就搞定。这时候静态编译就用上了。 简而言之，静态编译 Qt 不过是使用特殊的参数配置 Qt 而已： ./configure -release -opensource -static -no-gui -no-icu -no-glib -no-iconv -nomake examples 更详细的步骤请看原文吧。
下午花了一些时间测试 bcache 与 lvm cache 的使用。lvm cache 相对来说功能比较丰富，能够跟 raid1 一起组 lv，而 bcache 就只能简单地处理 cache。从安全性与性能的角度来看，我倒觉得 bcache 更为专业一些。接下来说一下 bcache 的基本使用： 首先要安装 bcache-tools # zypper install bcache-tools 由两个设备创建 bcache 是很简单的事，假设 sda 是 ssd，而 sdb 是 hdd, # make-bcache -w 4k -b 2m -C /dev/sda -B /dev/sdb 其中的-w参数指定底层设备的簇大小，而-b参数指定 bcache 管理的块大小。-C指定 cache 设备，-B指定 backend 设备。如果有多个 backend 设备可以写多个。
下载与简单使用 ZenStates-Linux： $ git clone https://github.com/r4m0n/ZenStates-Linux.git $ cd ZenStates-Linux $ sudo ./zenstates.py -l 上面这条命令会输出当前的 pstate 列表。正常可以看到 ryzen 1700 的 p0 是 3.0GHz $ sudo ./zenstates.py -p 0 -f 94 上面这个命令设置 p0 state 的频率是 3.7GHz
PyQt 现在还不支持从pip下载安装，习惯virtualenv开发的时候会比较麻烦，总不能为了一个 PyQt 就放弃了virtualenv吧。 有多种方案可以实现这个目标。我这里从源代码开始安装 PyQt，好像是不同的项目可以使用不同的版本。编译的时候我只编译了QtCore, QtGui, QtWidgets三个模块。 具体的步骤与命令看正文吧。
老鱼平常经常会纪录一些笔记，其中一部分放在这里，希望对大家有所帮助。
今天搞明白了，为啥 dos 有个 A20 地址线，以及 DOS 所谓高位内存的技术了。原因出在那个段地址的计算上面，经常看到的段的计算方式，实际上不止可以访问到 1M 的内存，而是 1M 再多一些： 0xffff * 16 + 0xffff 可以访问到比 1M 高一点的 64k 内存。实际上不是 64k，而是 64k-16 字节。因为 ffff:0010 就是 1M 比较早的 DOS 程序，会利用 8086 的 bug，访问这段内存实际上是访问 0000:0000 这一段内存。后来 80286 出现，这个 bug 就失效了。 由此引申出 DOS 内存的几个概念。
Qt 6.3 重镑发布了新的 Qt Quick 编译器，号称性能至少有 30% 的提升，能够以接近 native 的速度运行 Qt Quick 程序。我觉得这是一个在工程上相当漂亮的技术，所以在此做了一个介绍。 其基本原理是改造 QML 语言，现在已经不是一个纯粹的 JavaScript 了，而是类似于 TypeScript，能够在变量声明、函数参数、函数返回值添加类型标志。有了类型以后，Qt 提供了两个部件也就顺理成章了: QML 脚本编译器qmlsc，负责把 JavaScript 脚本编译成 C++ 代码。 QML 类型编译器qmltc，负责把 QML 文档编译成 C++ 代码。 脚本编译器仍然不能完整翻译动态的 JavaScript 语法，但是能够准确地识别其中 QML 类型的属性访问，算术指令和 ifelse 判断，循环等等结构并翻译成 C++. 其它的仍然被翻译成字节码供 QML 虚拟机解释执行或者 JIT. 目前脚本编译器暂时只对 Qt Device Creation 商业用户开放。普通的开源用户，仍然只能使用自 Qt 5.8 以来的qmlgencache. 而类型编译器，则能够比较准确地把 QML 文档翻译成 C++ 代码，目前这个 QML 类型编译器已经向所有 Qt 6.3 用户开放了。
在 openSUSE Leap 15.3 底下跨平台编译 mingw64 程序，只要安装跨平台编译的安装包就行了： sudo zypper in mingw64-cross-gcc-c++ 接下来我们就来操作一下: // main.c #include <stdio.h> void main() { printf("hello, world!\n"); } 然后运行: $ x86_64-w64-mingw32-gcc -o test003.exe main.c $ wine ./test003.exe 可以看到打印出结果。
使用 Python 开发的朋友们应该都知道 virtualenv 和 venv 创建虚拟环境了吧。 使用虚拟环境不会破坏 Python 的系统环境，也方便了布署，实在是非常好的编程实践。比较常用的几个 IDE，比如 PyCharm 和 Visual Studio 对虚拟环境的支持都不错。创建工程的时候可以选择一起创建虚拟环境，或者在 IDE 里面点几下搞定。实在非常方便。终端下则是 .env/bin/activate 激活。 不过虚拟环境要怎么布署呢。还有什么小技巧大家不知道的呢。本文跟大家分享使用 activate_this.py 和检测 python 解释器的两种小技巧。
Qt 为 windows 提供了一个在线安装包，以及一个巨大的离线安装包。使用在线安装包能够自由选择 Qt 版本。使用离线安装包可以在不需要网络地方或者在多台机器上使用。 但是两个安装器安装的 Qt 容量都太过于巨大了，包含了所有的 Qt 模块以及它们的 debug 信息。如果我们只使用 C++ 以及 QtWidgets 做 Qt 开发，就没必要安装那么多的组件，浪费空间。这时候可以考虑自己编译一下 Qt
在线系统经常需要存储用户名和密码等认证信息，以便在用户登录的时候认证密码。但存储密码的时候其实有很多学问。在原始的互联网时期，使用明文存储密码。在经历了多次严重的泄露事件以后，没过几年即使是最蠢的程序员都知道得在存储前使用 MD5 哈希一下。 现在我们已经知道使用 MD5 存储也不靠谱了。拿着 MD5 哈希后后的一串代码放到搜索引擎里面搜一下（彩虹表攻击），密码就出来了。对抗这种攻击的办法是给密码加盐，就是每次哈希前都带上一段随机字符串，并且和密码一起存储起来，这大大提高了破解的难度，即使你使用的是 123456 这么简单的密码，也不容易一眼就看出来了。
跟我打交道过的人都知道我一直在唱衰桌面端 Qt，但是又一直在推荐大家使用 Qt 作为服务端开发的标准库。服务端开发除了完成功能之外，还需要考虑到服务端运维。一般希望布署的程序越简单越好，只好不依赖于特定的系统，一个文件复制到服务端就搞定。这时候静态编译就用上了。 简而言之，静态编译 Qt 不过是使用特殊的参数配置 Qt 而已： ./configure -release -opensource -static -no-gui -no-icu -no-glib -no-iconv -nomake examples 更详细的步骤请看原文吧。
下午花了一些时间测试 bcache 与 lvm cache 的使用。lvm cache 相对来说功能比较丰富，能够跟 raid1 一起组 lv，而 bcache 就只能简单地处理 cache。从安全性与性能的角度来看，我倒觉得 bcache 更为专业一些。接下来说一下 bcache 的基本使用： 首先要安装 bcache-tools # zypper install bcache-tools 由两个设备创建 bcache 是很简单的事，假设 sda 是 ssd，而 sdb 是 hdd, # make-bcache -w 4k -b 2m -C /dev/sda -B /dev/sdb 其中的-w参数指定底层设备的簇大小，而-b参数指定 bcache 管理的块大小。-C指定 cache 设备，-B指定 backend 设备。如果有多个 backend 设备可以写多个。
下载与简单使用 ZenStates-Linux： $ git clone https://github.com/r4m0n/ZenStates-Linux.git $ cd ZenStates-Linux $ sudo ./zenstates.py -l 上面这条命令会输出当前的 pstate 列表。正常可以看到 ryzen 1700 的 p0 是 3.0GHz $ sudo ./zenstates.py -p 0 -f 94 上面这个命令设置 p0 state 的频率是 3.7GHz
PyQt 现在还不支持从pip下载安装，习惯virtualenv开发的时候会比较麻烦，总不能为了一个 PyQt 就放弃了virtualenv吧。 有多种方案可以实现这个目标。我这里从源代码开始安装 PyQt，好像是不同的项目可以使用不同的版本。编译的时候我只编译了QtCore, QtGui, QtWidgets三个模块。 具体的步骤与命令看正文吧。