Aptos 和 Sui 环境差异分析

免责声明：本文不构成投资建议，仅研究技术为主，祝玩得开心 ^_^

Aptos Move.toml

• 优势：一个 Aptos 可执行文件解决编译和部署能力
• 劣势：需手动配置钱包 Address

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[package]
name = "my_todo_list"
version = "1.0.0"
authors = []

[addresses]
todolist_addr='<YOUR_ADDRESS>'

[dev-addresses]

[dependencies.AptosFramework]
git = "https://github.com/aptos-labs/aptos-core.git"
rev = "devnet"
subdir = "aptos-move/framework/aptos-framework"

[dev-dependencies]

上节回顾

在【跟我一起编写 Buildpacks：Go 版本篇】中，我们将竭尽所能地分享从头开始构建的源代码，涵盖了从buildpack.toml到Go源码的全过程，旨在让大家能够迅速掌握如何编写 Buildpack。

在【跟我一起编写 Buildpacks：CICD 版本篇】中，我们深入探索用于为 Paketo 风格的 Buildpacks 创建 GitHub Actions 工作流的神器 Pipeline Builder，只需在仓库里配置两个文件即可完成 CICD 全流程。

本节，我们将继续分享 Buildpacks 相关的内容，本节的主题是 Meta-buildpack。

上节回顾

在【跟我一起编写 Buildpacks：Meta 篇】介绍了 Meta-Buildpack 的概念和用法，它是一个特殊的构建包，通过引用其他构建包来实现功能。可以通过配置文件中的顺序确定构建包的加载顺序。文章提供了一个示例来演示如何编写和构建 Meta-Buildpack。

本节，我们将继续分享 Buildpacks 相关的内容，本节的主题是 Builder。

程序如何运行：ELF二进制文件

前一篇系列文章描述了 Linux 内核在用户空间调用 execve() 时用于执行程序的通用机制。然而，那篇文章中描述的特定格式处理程序都将其执行过程推迟到一个内部调用 search_binary_handler()。这种递归几乎总是以调用 ELF 二进制程序为终结，这就是本文的主题。

PuzzleFS 项目地址：https://github.com/project-machine/puzzlefs

PuzzleFS 号称是下一代 Linux 容器文件系统，采用 Rust 语言编写，具有快速镜像构建、直接挂载支持、内存安全保证等功能。

PuzzleFS 项目介绍

思科开发者 Ariel Miculas 在内核邮件列表中，发布了用 Rust 写的 PuzzleFS 文件系统驱动，以征求其他开发者的意见，目前这一驱动程序处于“概念验证”阶段。

PuzzleFS 是一种只读的文件系统，与 Open Container Initiative (OCI) v2 image specification 的设计目标相符，它使用内容定义进行分块，并且使用内容寻址的数据存储，旨在解决现有 OCI 格式的限制。

OCI 镜像规范的第一个版本存在许多问题，这些问题的根源都是来自依赖 tar 存档来保存文件系统中的层，事实上 tar 不适合解决容器文件系统问题。

PuzzleFS 旨在解决 tar 的问题。文件系统镜像本身由一组放置在底层文件系统上的文件组成。与 OCI 镜像格式一样，存在一个顶级 index.json 文件，其中包含一组标签，每个标签代表某一个版本的文件系统，并指向一个清单文件（manifest file）。清单文件又指向镜像配置和存储在实际镜像层中的数据。其他所有内容都存储为 blobs/sha256 目录中的一组 blob。

文件系统中的大多数数据都被分成可变大小的块（chunk），以内容的 SHA256 哈希作为文件名来存储为 blob。这个分块动作本身是使用 FastCDC 算法进行的，该算法查找 “切割点（cut points）”，把数据流分为不同大小的 blob。任何一个特定的流（例如文件的内容）都可以分成五个或五十个块，这取决于如何确定这些切割点；然后，每个块都以不同的 blob 方式落在 blobs/sha256 下，并将其哈希添加到清单中。

前言

最近在学习 Rust 编写 Linux 网卡驱动时，发现了一篇有关网卡的精彩文章。英文原文请见此处。今天我将它翻译成中文，与大家分享。

这篇博客文章在之前的博客文章《监控和优化 Linux 网络堆栈：接收数据》基础上，通过一系列图表深入解释了 Linux 网络堆栈的工作原理，旨在帮助读者更清晰地了解其运作方式。

在监控或调整 Linux 网络堆栈方面，没有捷径可走。运维人员必须努力全面了解各个子系统及其相互作用，才能有望调整或优化它们。然而，之前的博客文章篇幅较长，可能让读者难以理解各个系统之间的交互关系。希望这篇博客文章能有助于澄清这些问题。

ArceOS Unikernel 总结报告

不知不觉，ArceOS Unikernel 课程的学习已经过去了一半。回顾过去这两周，我深感学习过程中的磨砺与成长。感谢石磊老师的细心指导，从基础概念入手，让我们逐渐掌握 Unikernel 的奥秘。谁曾想到，Unikernel 的设计竟如此强大。每次回顾这个过程，我都会重新阅读陈渝老师的著作《像开发应用一样开发操作系统》，从中汲取启示。我对操作系统可以如同应用一般，通过组件化思维实现感到震惊。过去曾听说过鸿蒙分布式部署等新闻，也阅读过一些关于鸿蒙的相关文章，但亲身参与组件化操作系统的学习，完全是不同于以往的体验。

课程总结

第一周练习主要包含以下内容：

• 首先，通过彩色打印 “Hello World” 和支持 Hashmap 数据类型的示例，快速熟悉 ArceOS 架构
• 接着，实现 early 内存分配算法，深入了解 ArceOS 的内存分配流程
• 最后，将协作式调度算法 FIFO 改造为抢占式调度算法，为第一周的学习画上圆满句号

通过本周学习对 ArceOS 的整体架构、内存分配及调度算法有更深入的了解。

本节课一起动手实践 Hello World 内核模块，逐步剖析驱动程序的开发过程，从而掌握 Linux 驱动的基本知识。

不知不觉，我已经步入清华训练营的第三阶段。第一阶段主要学习了 `Rust` 编程语言，并完成了 `Rustlings` 题目训练。在第二阶段，老师引导我们运用 `Rust` 从零开始构建一个小型操作系统。在这个过程中，我掌握了从裸机、批处理程序、分时系统、地址转换，到虚拟地址与物理内存页表映射处理，再到进程管理、文件系统以及并发设计等知识。一个名为 `rCore OS` 的操作系统便如此一步步地呈现在眼前。作业撰写属实不易，历经艰辛，我终于迎来了第三阶段。在这个阶段，我选修了《Rust fox Linux》课程，以期为未来的 `Linux` 设备驱动开发贡献力量。昨日是课程的第一节课，我又开始了各种环境准备工作。

在 RISC-V：跟着清华训练营从零打造OS【第四课】中，我们主要讲解了文件系统在操作系统中的重要性，并讲述了UNIX操作系统的创始人 Ken Thompson 在编写一个测试程序时，意识到可以将其扩展成一个文件系统，从而创造了UNIX操作系统的故事。还介绍了EasyFS文件系统的设计和实现，包括常规文件和目录文件的新增，以及文件系统的核心数据结构和块缓存管理器的实现。最后，还介绍了EasyFS的五个不同层次的设计和相关接口代码定义，本节课是第二阶段最后一节课，主要讲解进程间通信、I/O重定向和并发的设计。