Posts

学汇编语言肯定还是要练习的，ZJUT 的汇编课程使用的汇编语言是微软的 MASM。 最理想的实验环境就是 DOS 系统。 Dos 模拟器 哥们的这篇文章中用的 dosbox 其实并不好用: 例如无法迅速调整界面字体大小，导致在高分辨环境下十分瞎眼。 笔者推荐使用 dosbox-staging. 在 Archlinux 下安装: 1 paru -S dosbox-stagin-bin 开箱即用，十分方便。 配置 下载常用工具 （上述连接也是哥们的服务，笔者比较懒hhh） 解压到某一个文件夹中，例如笔者是 ~/Learn/asm/tools Dos模拟器需要手动挂载盘符，而且没有添加 PATH 变量的情况下十分甚至九分的难用。 在配置文件 ~/.copfig/dosbox-staging.conf 最后（autoexec块）后加上 1 2 3 MOUNT C: path/to/your/dir C: SET PATH=%PATH%;C:\TOOLS 上述命令假设你的工作目录下的tools目录中为masm.exe等 DOS 系统不区分大小写 除此之外 masm 在进行汇编以及 link 进行链接的时候还需要敲一堆回车，为了方便笔者编写了以下的 bat 批处理文件 1 2 3 4 5 echo compile and run %1 masm %1.asm %1.obj nul.lst nul.crf link %1.obj, %1.exe, , , , %1....

昨天(2023年10月31日) Typst 发布了 0.9.0 版本。 我最关注的更新内容是参考文献格式的更新，引入了 CSL (Cite Style Language)支持，理论上可以自定义参考文献格式。而且默认支持了中国国标 GB/T 7714-2015 和 GB/T 7714-2005 格式。 但是同时引入了几个 Breaking Change Changelog: https://github.com/typst/typst/releases/tag/v0.9.0 也对 hayagriva 引入了几个 Breaking Change 如何使用自定义的参考文献格式 只需要在 #bibliography中制定 style 属性即可： 1 2 3 something something @test #bibliography("bib.yaml", style:"gb-7114-2015-numeric") 然而在笔者试用的过程中发现GB/T 7714-2015 的格式存在问题，自己去下了一个 .csl 文件也是错的。（渲染结果可看issue) 于是应该是 typst 编译器存在问题了，笔者已经提交了一份 issue: https://github.com/typst/typst/issues/2548 静待修复罢（

近期 Neovim 生态变化 最近几个月(2023下半年) Neovim 的插件生态发生了很大的变化. Packer.nvim 停止维护 首先是高达 7.2k stars 的插件管理器 Packer.nvim 在今年八月宣布停止维护. 而笔者在使用 neovim 的时间内都在使用 packer.nvim. 作为现代 neovim 的最重要的工具之一, 插件管理器必须使用被长期维护的, 因而笔者决定切换到 lazy.nvim lazy.nvim 的界面更为美观, 而且有高度灵活可以自定义的懒加载 hook, 从而大大提高启动速度. null-ls.nvim 停止维护 之前依赖 null-ls 的诸多功能可能在未来一段时间后 break. 所以必须找到一个可以替换 null-ls 的工具. Neovim 配置思路 笔者并不认为读者 应当 照抄某人的配置, 因为其按键绑定, 插件的使用习惯等等都会不同. 因而笔者写作本文旨在描述一个具有拓展性的配置. 笔者总结了以下几个原则: 1. 使用 Lua 作为配置的脚本语言 作为一个 neovim 用户, 自然要使用作为 一等公民 的 lua 作为配置脚本语言. 这将保证配置文件的长期可用性. 所有配置的入口文件则是在nvim 配置目录的根目录下的 init.lua 文件中. 2. 模块化配置 笔者认为作为一个具有在无图形化界面条件下对服务器进行运维功能的编辑器, 应该拥有一个 “最小模式”. 最小模式应当包括所有的按键绑定和其他基础的界面等等的配置. 并且不能配置特殊的字体, 不能配置插件(毕竟你的设备可能由于种种原因无法正常使用国际互联网) 此外不同 种类 的配置应该被放置在不同的文件中, 以供检索和修改....

今年八月我参加了我校的游学项目。 项目分为两部分，前半个月参观了欧洲德国、比利时、意大利、奥地利、捷克、斯洛文尼亚等国的几个城市。 后一部分是在亚琛工业大学进行的 Python 有关的课程，也有一些校方安排的活动。 本文写在即将离开亚琛，即将结束这段行程前，对我，半个也到一个月在德国“准生活”的一个回顾。 气候 最直接的感受是气候：德国的气候整体偏凉爽，个人感觉是很舒服的，确实不需要安装空调。甚至入秋以后，晚上睡觉会感觉到冷，在最后这几天（八月份下旬）我每天的服装已经是必须要穿衬衫的了。 德国的雨水很大，雨水来的快去的快，雨过后天晴很快。 雨伞在德国是必需品。 所以在这边，风衣、夹克等是很常见并且很实用的。 德国的纬度高，日照时间很长，夏天九点天才会大黑。不过德国人基本上很少有夜生活，晚上在外面基本上没多少人。 生活 公共交通 在亚琛，公共交通相当发达。 公交车可以坐到任何一个地方。 公交车上也很少有拥挤的情况， 说一个细节：公交车上有划定给婴儿车和轮椅放置的位置， 除此之外德国的公交车可以向右边倾斜，以便于婴儿车、轮椅等上下。 我亲眼所见的是一个妈妈推着两个婴儿车坐公交。 饮食 饮食其实每个人有每个人的主观感受，我个人的感受是完全能适应西餐。 德国的肉类、奶制品的质量比国内要高。香肠、肉饼、各种奶酪、各种酸奶。 欧洲的早餐似乎都很统一：各种面包+各种香肠+各种酸奶+咖啡/茶 等等 我觉得我是能吃得惯的：我在这边的早餐一般都是两个欧包或者是一个欧包+两片面包，再加n杯果汁，一碗酸奶，一杯咖啡。 欧包我会从中间破开，夹入2、3片不同的香肠，夹入一点奶酪，还有一片芝士片。 德国香肠很棒，德国的猪排等等也很棒。 本人滴酒不沾，所以无法对德国啤酒做出评价。 吃饭的价格很便宜，一顿很好的餐（例如一个猪排、沙拉、薯条，再配一杯可乐）最多10欧。 实际上我最喜欢的 Döner Sandwich 或者是 Döner Wrap 只需要 6，7欧（就能吃饱）^[1]在大学食堂就更便宜了。 [1]:FYI, 德国最低时薪13€ 楼层 这个标题似乎看起来很奇怪， 不过德国这边的楼大多数都是从0层开始计数的，和国内不同。 支付 很少有地方只收现金，但是还是有的。 来德国不管是旅行还是留学必须要有的一样东西就是钱包：而且有可以装零钱的夹层的钱包 因为欧元5元以下是没有纸币只有硬币的。 RWTH 亚琛工业大学，实际上叫 RWTH （Rheinisch-Westfälische Technische Hochschule） RW似乎是莱茵-威斯特法伦， T就是工业/技术 Hochschule 是高度学院， 可以感受到的是这里的华人留学生很多， 在市中心的学校旁边，有连续好几家中餐馆， 我去吃的时候里面坐满了中国人。 德国人 印象深刻的德国人 在亚琛主火车站(Aachen Hauptbahnhof) 旁边的一家 Döner Haus， 里面有个很可爱的大叔，留着一字胡，打破了对德国人不懂幽默的刻板印象。 第一次进去点单，点了一个 Döner Sandwich，大叔用不知道什么语言（很可能是德语）问我要什么酱料，指着辣酱做了一个手舞足蹈的表情，很可爱。...

在 TypeScript & JavaScript 中有众多的有关“空”、“未定义”的类型: null undefined void never unknown 本篇文章将辨析以上这些类型。 TypeScript 的类型 需要注意的是 TypeScript 只是将 ts 语句翻译为 js。换言之 ts 并没有运行时的类型强制。 因此在运行时使用 typeof 并不会显示 void, never 等 ts 特有的类型。 Null & Undefined Null 和 Undefined 是 JavaScript(ECMAScript) 中就存在的两个类型。 众所周知的是一个变量（or 对象）必然由两个元素组成： 数据和结构(即类型)。 在 ECMASCript6 标准中 Undefined 和 Null 是两个基本数据类型，而他们分别之对应了一个值，即为 undefined 和 null. 二者的区别细微: null 的本质是一个 object，而 undefined 不是 1 2 3 4 5 6 7 let a; // undefined let b = null; // undefined a == b; // true typeof a; // undefined typeof b; // object let c = Number(a); // c == NaN let d = Number(b); // d == 0 Void 表示空，通常定义到没有返回值的函数上。...

原作者 Mark Smallcombe 原文 PostgreSQL vs MySQL: The Critical Differences | Integrate.io 数据类型支持：PG支持更多的类型（数组、JSON、哈希表、地理数据） SQL 规范性 PG 对高阶的SQL标准有更好的遵循 MySQL 过去有一些与严格的SQL标准的偏差，不过在最新的版本中提升了规范性，并且在继续弥合这种偏差 性能： MySQL 已被证明适合读取密集型工作，这使得它更适合web应用和网页 PG 的架构更适合复杂的查询和分析工作，适合在需要高级SQL特性的场景下工作 复制和高可用： MySQL 提供多种复制方法，包括主从复制，但是它的一些聚类解决方案可能需要第三方工具。 PG 提供内置的同步复制，更容易实现高可用和数据冗余 全文搜索： PG 包含了开箱即用的鲁棒的全文搜索能力，允许复杂的文本搜索操作 MySQL 也支持全文搜素，但需要额外的配置以及外部引擎例如InnoDB或者MyISAM 外键约束和触发器： PG有对外键约束和触发器的高级支持，使得它是有复杂的数据完整性和业务规则的程序的更好选择 MySQL 也有外键约束和触发器，但是过往并不严格执行这些 许可证： PG 使用 PostgreSQL License MySQL 使用 GPL，但是现在也提供商业许可

这是我gRPC系列的第二篇， 上一篇是 gRPC系列：（1）Protobuf 简要介绍 | Finley’s Blog 前言 这篇文章将开发一个简单的测试项目，使用 Golang 作为服务器， 前端将使用三种不同的技术：Golang 的 cli 项目、Flutter 的 Desktop 项目、Vue (gRPC-Web) 这篇文章将在简要介绍gRPC的基础上，开发一个 Golang 的gRPC 服务器，并且使用 gRPCurl 和 Apifox 进行测试。 Proto 设计 编写 proto 文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 syntax = "proto3"; package user; option go_package = "/api"; import "google/protobuf/empty....

这是 gRPC 系列博客的第一篇，本篇将简要介绍 Protobuf 这一gRPC定义语言。 Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data. (笔者译：Protocol Buffers 是一个语言中性的、平台中性的拓展性序列化结构数据的机制) Protocol buffers are a combination of the definition language (created in .proto files), the code that the proto compiler generates to interface with data, language-specific runtime libraries, and the serialization format for data that is written to a file (or sent across a network connection). (笔者译：Protocal Buffers 是下列功能的集合：定义语言（通过.proto文件)、生成接口和数据代码的 proto 编译器，特定语言的运行库、以及存储到一个文件（或通过网络传输）的序列化格式...

引言 程序的并发实现方式，常见的无非如题所述的三种： 线程、进程和协程。本文将总结三者的区别，以及在 python 和 golang 等语言中的实际应用。 并发、并行、异步、同步 并发 (Concurrency)，是指在同一段时间内执行多个程序 并行（Parallelism），是指在同一刻有多个程序在同时执行 并发可以理解为两个（或多个）程序表现上能同时进行。 而真正意义上的同时，对于单核CPU，真正意义上的并行（在某一个时刻，同时运行多个程序）并不存在。 因此从直白的说，并发是一种程序的调度技术，使CPU的空闲时间降低，而大大提高效率。 CPU 本身也有并发技术，如中断机制、流水 CPU、DMA等等，这并非是本文的重点。 异步（Asynchrony)，是指多个程序的运行并没有时间上的顺序关系 非阻塞（Non-blocking），是指程序的执行过程中不存在等待，是异步的实现 同步（Synchrony)，和异步相对，程序的运行有时间上的顺序，通常会有阻塞 阻塞 (Blocking)， 是指任务执行过程中的暂停或等待，通常是为了实现同步 在时序逻辑电路中也有同步和异步的概念，同步的时序逻辑电路通常引入一个统一的时钟信号。 并发安全 程序的并发需要考虑的一个问题就是并发安全。 对于一段数据，由于并发的存在，可能存在脏读的情况。 一般的解决方式是通过加锁的方式，产生一定程度上的阻塞，从而避免并发导致的数据冲突。 能避免由于并发而造成的数据冲突的数据结构称之为并发安全的（或是线程安全的） 线程 线程 (Thread) 是 CPU 调度的最小单位。也就是说子线程的执行先后顺序是由CPU决定调度的。 一个进程可以有多个线程。 Python 中多线程的实现 1 2 3 4 5 6 7 8 9 10 11 12 13 import threading def sub_program(name: str) -> None: for _ in range(5): print(f'Hello {name}') def main() -> None: threads = [threading....

引言 最近在研究 gRPC 的 TLS 通信， 是时候整理一下这几个相似概念了。 TLS Transport Layer Security 传输层安全协议 SSL Secure Sockets Layer 安全套接层 HTTPS HyperText Transfer Protocol Secure 超文本传输安全协议 SSH Secure SHell 安全外壳协议 TLS/SSL 网景公司（Netscape）在1994年推出首版网页浏览器－网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。 TLS 的前身是 SSL，因此在很多场合，两者是混用的（或者是直接称之为 TLS/SSL ) 公钥/私钥 背景知识：对称加密和非对称加密。 简单来说有三点： 对称加密只有一个密钥：也就是说通过密钥加密，也通过密钥解密 非对称加密有公钥和私钥：通过公钥加密的信息只能通过私钥解密；并且无法通过公钥得到私钥。 对称加密的效率要高于非对称加密 服务器端掌握公钥和私钥， 客户端掌握公钥（或者说是服务器向客户端发送公钥） 以下将描述两个场景： 场景1 通过 HTTPS 协议访问网站 客户端请求服务器 服务器返回公钥证书 客户端验证公钥证书是否合法 产生随机对称密钥，通过公钥加密后发送给服务器 服务器同私钥解密后，使用对称密钥进行对称加密通信 场景2 客户端访问访问服务器 客户端内携带公钥证书 客户端产生随机密钥，通过公钥发送给服务器 服务器通过私钥进行解密 使用密钥进行对称加密的通信 我想读者此时有几个问题： Q1: 为什么不能使用对称加密呢？ A: 客户端和服务端必须同时拥有密钥才能进行通信，那么在这个过程中理论上密码就会有泄漏的风险：想象一下，密钥一定是从服务端或者客户端生成的，需要将密钥传给另一端的过程中必然经过危险的网络环境。因此单纯的对称加密是不可行的。 Q2: 为什么不能全部使用非对称加密呢？ A：因为非对称加密的效率不如对称加密。通过安全的方式将对称加密密钥送到另一端，那么对称加密也是安全的。 HTTPS HTTPS 也就是使用TLS 的HTTP，也就是上一小节中提到的场景1的情况。...