操统实验日志 第一章 序章
简述
+操统实验日志 第一章 序章
简述
在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
它是关于什么的
diff --git a/2022/07/15/os-journal-vol-2/index.html b/2022/07/15/os-journal-vol-2/index.html index 1b9596a..bb3265d 100644 --- a/2022/07/15/os-journal-vol-2/index.html +++ b/2022/07/15/os-journal-vol-2/index.html @@ -7,7 +7,7 @@ - + @@ -166,7 +166,7 @@ isHome: false, isHighlightShrink: false, isToc: true, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }操统实验日志 第二章 万丈高楼平地起
关于本章
+操统实验日志 第二章 万丈高楼平地起
关于本章
本章的序将会首先介绍操作系统是如何运行起来的，并在此基础上介绍实现一个完备的操作系统实验需要实现哪些方面，以及这些部分的先后顺序和依赖关系
由于这份文档我并不打算作为一份完备的教程文档来编写，因此语言方面的介绍会相对简略或是跳过，对应的详细介绍可以参考学校的同步教程
在本章的后半部分，将会介绍MBR和中断的相关知识，记录如何编写MBR、测试使用BIOS启动MBR引导程序并通过中断输出字符串进行测试
diff --git a/2022/07/19/os-journal-vol-3/index.html b/2022/07/19/os-journal-vol-3/index.html index bafd921..2f050f4 100644 --- a/2022/07/19/os-journal-vol-3/index.html +++ b/2022/07/19/os-journal-vol-3/index.html @@ -7,7 +7,7 @@ - + @@ -166,7 +166,7 @@ isHome: false, isHighlightShrink: false, isToc: true, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }操统实验日志 第三章 从实模式到保护模式
关于本章
+操统实验日志 第三章 从实模式到保护模式
关于本章
在本章的第一部分中，将会介绍读取硬盘的CHS方式、LBA方式以及如何通过in、out指令读写硬盘，之后会将上一章输出Hello World!的代码移植到BootLoader中，并且从MBR中加载并跳转到编写的BootLoader执行
在第二部分中，会回顾保护模式的概念并介绍进入保护模式的四个步骤，并在开启保护模式之后输出第二个Hello World
第一次跃进：从MBR跳转到BootLoader
diff --git a/2022/08/20/os-journal-vol-4/index.html b/2022/08/20/os-journal-vol-4/index.html index b6760a3..2182294 100644 --- a/2022/08/20/os-journal-vol-4/index.html +++ b/2022/08/20/os-journal-vol-4/index.html @@ -7,7 +7,7 @@ - + @@ -166,7 +166,7 @@ isHome: false, isHighlightShrink: false, isToc: true, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }操统实验日志 第四章 勇者之路
关于本章
+操统实验日志 第四章 勇者之路
关于本章
在本章节的第一部分中，将会简要介绍在下一章中将要编写的KernelLoader，以及在开始着手进行它的编写之前所需要完成的，包括各种驱动、文件系统接口等在内的诸多准备工作。
在第一部分之后，我决定按照KernelLoader中的函数调用顺序，逐节完成KernelLoader中所需要的所有准备工作，因此在第二部分中，将会首先记录如何在项目中使用C语言和汇编混合编程，包括C语言是如何进行函数调用的，以及内联汇编中NASM向AT&T迁移语法所需要注意的问题。有了这部分基础知识，就可以进行第三部分编写一些常用的驱动，并从我个人的角度讲讲为什么要这么做，它对后续的代码编写能够起到哪些帮助。
在之后的第四部分中，会进行有关文件系统的知识的详述，并且带领大家阅读微软关于FAT文件系统的文档，根据文档完成FAT文件系统接口的设计和实现。
diff --git a/2024/10/11/reborn/index.html b/2024/10/11/reborn/index.html index edf8828..717d0b1 100644 --- a/2024/10/11/reborn/index.html +++ b/2024/10/11/reborn/index.html @@ -7,7 +7,7 @@ - + @@ -165,7 +165,7 @@ isHome: false, isHighlightShrink: false, isToc: false, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }重生
时隔两年，终于借着重新配置家里网络环境的契机，重新搭建了这个博客。
+重生
时隔两年，终于借着重新配置家里网络环境的契机，重新搭建了这个博客。
原先关于操作系统的文章正在慢慢搬迁，应该很快就能恢复了~
再一次启用关于自己的博客，感觉心里良多感慨。还记得上一次搭博客时的自己，刚来到计算机学院，对着网上的保姆教程在腾讯云的小机器上搭了 git 仓库、配置了宝塔面板、DNS 解析。
那时的自己对 TLS、证书、Git、反代、CDN、Docker 这些东西都还是那么陌生，以至于教程之外的东西完全不敢去碰，哪怕是在宝塔面板上配一个 Let’s Encrypt 的证书都要折腾好久，也没有去研究 hexo deploy 到底 deploy 了什么到服务端，只觉得能跑便是好事，这也就导致了后来的删库跑路事件——本地的博客仓库被主动删除，等到发现服务器上是没有 Markdown 源文件的时候已经太迟，由于没有了源文件，写新的博客势必会导致旧的 html 被覆盖，又因为文章实在太长迟迟没有动手迁移，原先的数万字长文就这样被冻在了旧的博客里长达两年。
基于 IPv6 公网地址、NAS 和 MacMini 的私有部署博客方案
方案速览
简单来说，方案分为了几个主要的部分：
+基于 IPv6 公网地址、NAS 和 MacMini 的私有部署博客方案
方案速览
简单来说，方案分为了几个主要的部分：
- 根据 在 NAS 上部署自己的 Gitea 服务，无需公网服务器 方案打通外网到家用 NAS / MacMini 的链路
- 采用 Git 仓库 main 分支存放源码 + Gitea Actions 编译至 publish 分支实现源码及制品存储 diff --git a/2024/10/13/blog-mig/index.html b/2024/10/13/blog-mig/index.html index 5c86415..9dad90d 100644 --- a/2024/10/13/blog-mig/index.html +++ b/2024/10/13/blog-mig/index.html @@ -7,7 +7,7 @@ - + @@ -167,7 +167,7 @@ isHome: false, isHighlightShrink: false, isToc: false, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }
- 正文前部的各种元素，例如头图、导航栏、侧边栏等 diff --git a/2024/10/13/host-git-at-home/index.html b/2024/10/13/host-git-at-home/index.html index 8230033..879a016 100644 --- a/2024/10/13/host-git-at-home/index.html +++ b/2024/10/13/host-git-at-home/index.html @@ -7,7 +7,7 @@ - + @@ -165,7 +165,7 @@ isHome: false, isHighlightShrink: false, isToc: true, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }
- 公网访问使用光猫桥接路由器拨号，通过路由器同时获取 IPv4 大内网和 IPv6 公网 /64 地址
- DNS 解析通过 MacMini 上部署的 ddns-go 实现 diff --git a/2024/10/13/micro-posts/index.html b/2024/10/13/micro-posts/index.html index d6b31e8..5b8f15f 100644 --- a/2024/10/13/micro-posts/index.html +++ b/2024/10/13/micro-posts/index.html @@ -7,7 +7,7 @@ - + @@ -167,7 +167,7 @@ isHome: false, isHighlightShrink: false, isToc: false, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }
.dex文件方式：-
@@ -272,7 +272,7 @@ btf.addGlobalFn('pjaxSend', () => {
- 在研究
atx/uiautomator2的实现的时候，先入为主地就认为作者使用了uiautomator <jar>这种方式调用，后面注意力都放在了查找作者针对u2.jar的打包方式和相关代码上了，以至于在仓库里搜索u2.jar的时候竟然没有注意到在搜索结果中core.py赫然有着command = "CLASSPATH=/data/local/tmp/u2.jar app_process / com.wetest.uia2.Main"这一启动方式，与答案擦肩而过并且进一步在寻找 uiautomator 1.0 的打包方式上浪费了大半天的时间 - 对于一个陌生的仓库，如果想要了解它的源码实现，不一定非要自己去读，除了进行仓库里的关键词搜索，也可以去查找别人的源码解析，走个捷径
- 在研究
- 用文件资源管理器定位到需要 Clone 到的位置然后右键呼出终端
git clone
diff --git a/2024/11/22/debug-windows-socket-drain/index.html b/2024/11/22/debug-windows-socket-drain/index.html
index 292d8e5..29d3b1d 100644
--- a/2024/11/22/debug-windows-socket-drain/index.html
+++ b/2024/11/22/debug-windows-socket-drain/index.html
@@ -7,7 +7,7 @@
-
+
@@ -166,7 +166,7 @@
isHome: false,
isHighlightShrink: false,
isToc: true,
- postUpdate: '2024-11-22 16:30:16'
+ postUpdate: '2024-11-22 16:49:44'
}- 是哪个进程在大量发起这样的请求？是否符合预期？
短文 - 博客迁移小记
最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
短文 - 博客迁移小记
最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
直到今天突然意识到，hexo 渲染 markdown 为 html 文本肯定会分为三个大部分：
在 NAS 上部署自己的 Gitea 服务，无需公网服务器
方案速览
简单来说，方案包含了以下几个主要部分：
+在 NAS 上部署自己的 Gitea 服务，无需公网服务器
方案速览
简单来说，方案包含了以下几个主要部分：
短文 - 关于短博文的碎碎念
感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
+短文 - 关于短博文的碎碎念
感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
看到 Hexo - Butterfly 有提供一个 “说说” 的页面可以用 .yml 格式来存一些说说文档，但是仔细一看发现好像不会自动分页，这样一来图片一多感觉加载就会变成彻底的灾难…
不知道为什么在静态编译的时候没有做成本地分页的格式呢… 就像文章那样，其实在编译阶段就可以分散到不同的 index.html 去了，好可惜，也许以后有空会想办法看看能不能改吧…
还有很多云存储的方案，但感觉把自己的内容放在云上，总感觉会比较担心数据安全和以后的迁移成本，纯本地的话哪怕一天发两条十年也不过才不到上万条数据，一个 .yml 就带走了，哎可惜没分页终究还是不打算去用。
短文 - 转正日
今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
+短文 - 转正日
今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
对自己的期望就是，不要忘记做技术的初心，在新的阶段能有所成长，有所收获。
Po 一张在鹅厂的第一个关爱里程碑~
用 adb + app_process 执行 Java 代码 —— 一种无需安装 apk 的脱机代码执行方案
方案速览
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
用 adb + app_process 执行 Java 代码 —— 一种无需安装 apk 的脱机代码执行方案
方案速览
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
对于目标 .jar 或是 .dex 文件，有两种不同的编译方案：
短文 - 面对首次绩效考核的一些随笔
快要到年底绩效考核的时间了，回想过去半年好像一直忙忙碌碌但好像又没有什么很亮眼的成果。期间还有一大部分精力都投在了一个设计难度远大于实现难度的需求。
+短文 - 面对首次绩效考核的一些随笔
快要到年底绩效考核的时间了，回想过去半年好像一直忙忙碌碌但好像又没有什么很亮眼的成果。期间还有一大部分精力都投在了一个设计难度远大于实现难度的需求。
回过头想想，其实在工作上开始做一件长期的事情之前，还是要去评估可行性、投入以及收效，到底这件事情有多大的优先级，是不是就值得现在立马开始投入人力去做这个。到底做些什么可以被业务感知到，从而去判断，到底哪些需求才是重要的，而不是一味的承接需求，最后反倒抓不到重点了。
当然，除此之外，更重要的一点是，在知道了公司存在强制的 Underperform 比例时，不免会想，也许有一天我也要成为背这个绩效的人？在这种场景下，是否不要把鸡蛋放在一个篮子里更为安全？诚然，上班本质还是一种利益交换，我给公司提供我能够产出的内容，帮助公司节省人力开支或是做原本人力做不了的事情，公司给我反馈大厂背景、经验、人脉和钱，当然，这里面必然伴随着剩余价值的剥削云云，但总的来看，也算是目前相对公平且不错的买卖，在这样的背景下，我还是会在工作的时候专注于需求本身，坚守住技术人应有的底线，但在工作时间之外，确实应该更加关注自身的投资，也许是身体的健康，也许是产品思维，也许真的去做一些能代表自己实力的东西吧。
前几天有看到一个帖子，个人认为说的其实很有道理，大致意思就是，人总要有一些能证明自己能力的东西，在校招的时候，学历就是最大的背书；在工作的时候，便是绩效和公司、项目经历。但是，如果能有足够的其他履历，比如大的开源项目、成功的产品，这些就会替代前者变成能力的证明，毕竟，选择前者只是没有后者的无奈之举。所以，我想，做自己感兴趣的事，并且在这方面出彩，大概才是最有价值的投资吧。
diff --git a/2024/11/08/linux-commands/index.html b/2024/11/08/linux-commands/index.html index 253edc5..4de3ddb 100644 --- a/2024/11/08/linux-commands/index.html +++ b/2024/11/08/linux-commands/index.html @@ -7,7 +7,7 @@ - + @@ -168,7 +168,7 @@ isHome: false, isHighlightShrink: false, isToc: false, - postUpdate: '2024-11-22 16:30:16' + postUpdate: '2024-11-22 16:49:44' }长更 - Linux 常用指令
先挖坑，慢慢填
+长更 - Linux 常用指令
Listary 命令分享 - 快捷 clone 仓库并使用 VSCode 打开
背景
日常工作中，经常会需要临时 Clone 某个仓库并且用 VSCode 打开，在 Windows 上我一般都是：
+Listary 命令分享 - 快捷 clone 仓库并使用 VSCode 打开
背景
日常工作中，经常会需要临时 Clone 某个仓库并且用 VSCode 打开，在 Windows 上我一般都是：
问题定位回顾 - Windows 上发起 tcp 连接时提示 Only one usage of each socket address (protocol/network address/port) is normally permitted
问题背景
某天在 Windows 宿主机上执行任务时，发现 wda 指令请求一直失败，查看日志发现唯一有效的错误日志是 Only one usage of each socket address (protocol/network address/port) is normally permitted，回顾宿主机环境在过去一段时间没有进行过变更，并且该问题是第一次出现，此前相同环境并没有出现过这个问题
问题定位回顾 - Windows 上发起 tcp 连接时提示 Only one usage of each socket address (protocol/network address/port) is normally permitted
问题背景
某天在 Windows 宿主机上执行任务时，发现 wda 指令请求一直失败，查看日志发现唯一有效的错误日志是 Only one usage of each socket address (protocol/network address/port) is normally permitted，回顾宿主机环境在过去一段时间没有进行过变更，并且该问题是第一次出现，此前相同环境并没有出现过这个问题
尝试在其他宿主机以及本地开发机上执行相同命令均不能稳定复现该问题，其中 Linux 开发机无法复现该问题
定位过程
报错分析
由于报错信息只有一行，也只能从这个信息来入手。搜索引擎检索得到如下内容：
@@ -216,7 +216,7 @@ btf.addGlobalFn('pjaxSend', () => {Windows 侧动态端口范围分析
先关注第一个问题，通过检索搜索引擎 windows dynamic port range 可以检索到如下文档：
-The default dynamic port range for TCP/IP has changed since Windows Vista and in Windows Server 2008：*To comply with Internet Assigned Numbers Authority (IANA) recommendations, Microsoft has increased the dynamic client port range for outgoing connections in Windows Vista and Windows Server 2008. The new default start port is 49152, and the new default end port is 65535.*，也即 Windows 上的默认动态端口范围自 Windows Server 2008 开始，默认从 49152 开始到 65535，一共 16384 个，同时使用 netsh int ipv4 show dynamicport tcp 可以查看实际配置的值
The default dynamic port range for TCP/IP has changed since Windows Vista and in Windows Server 2008：To comply with Internet Assigned Numbers Authority (IANA) recommendations, Microsoft has increased the dynamic client port range for outgoing connections in Windows Vista and Windows Server 2008. The new default start port is 49152, and the new default end port is 65535，也即 Windows 上的默认动态端口范围自 Windows Server 2008 开始，默认从 49152 开始到 65535，一共 16384 个，同时使用 netsh int ipv4 show dynamicport tcp 可以查看实际配置的值
Powershell 执行 netsh int ipv4 show dynamicport tcp，确实得到 16384 这个结果：
1 | 协议 tcp 动态端口范围 |