feat: deploy github page

zh-cn/assets/index-12a2a854.js → zh-cn/assets/index-047539e4.js

@@ -1,4 +1,4 @@
-const o="/zh-cn/assets/cover-9c53ea5f.png",t="/zh-cn/assets/imgae1-084eb861.jpg",e=[o,t],n={label:"硬件敏捷开发与验证方法学研讨",description:"作为2022年第二届RISC-V中国峰会的同期活动，8月27日下午，达坦科技将在线上举办硬件敏捷开发与验证方法学研讨。",cover:"./cover.png",location:"新加坡",date:"2022-08-23",title:"Hardware Agile Development and Verification Methodology Workshop"},s=[],r=`<p>作为 <strong>2022 年第二届 RISC-V 中国峰会</strong>的同期活动，8 月 27 日下午，达坦科技将在线上举办硬件敏捷开发与验证方法学研讨。</p>
+const o="/zh-cn/assets/cover-9c53ea5f.png",t="/zh-cn/assets/imgae1-084eb861.jpg",e=[o,t],n={label:"硬件敏捷开发与验证方法学研讨",description:"作为2022年第二届RISC-V中国峰会的同期活动，8月27日下午，达坦科技将在线上举办硬件敏捷开发与验证方法学研讨。",cover:"./cover.png",location:"新加坡",date:"2022-08-23",title:"Hardware Agile Development and Verification Methodology Workshop"},s=[],l=`<p>作为 <strong>2022 年第二届 RISC-V 中国峰会</strong>的同期活动，8 月 27 日下午，达坦科技将在线上举办硬件敏捷开发与验证方法学研讨。</p>
 <p>如何提升数字芯片的开发和验证效率一直是业界关注的焦点。近年来随着 Chisel、SpinalHDL 等等一众新一代 HDL 的推出，业界逐步感受到新一代 HDL 在数字芯片设计效率方面的提升。相比 Verilog 和 VHDL，这些新一代 HDL 在语法表达能力、代码简洁程度、错误检查等方面有不小的提升；相比高阶综合 HLS，这些新一代 HDL 支持 RTL 级描述能力，在芯片性能的把控方面远超 HLS。此外，基于 Python，以 Cocotb 和 pyuvm 为代表的新一代验证框架的推出，使得验证的周期得到一定程度的缩减，特别是基于 Python 的验证框架可以复用 Python 生态丰富的已有工具和模型，大大减少了 Golden Reference 的工作量。</p>
 <p>更重要的是，这些新一代 HDL 打开了全新的数字芯片敏捷设计和验证的方法学大门。本次研讨将邀请业界多位专家分享他们在各自领域的<strong>硬件敏捷开发与验证实践经验</strong>，为业界提供一次深入探讨和交流的机会，促进硬件敏捷开发与验证方法学的发展与落地。</p>
 <p>参与本次研讨的听众可以深入了解业界关于硬件敏捷开发与验证的最前沿探索，诸如：</p>
@@ -11,4 +11,4 @@ const o="/zh-cn/assets/cover-9c53ea5f.png",t="/zh-cn/assets/imgae1-084eb861.jpg"
 <p>活动时间：8 月 27 日，13:15-17:15<br>
 活动链接：<a href="https://t.elecfans.com/live/2113.html">https://t.elecfans.com/live/2113.html</a><br>
 感兴趣的听众可以添加海报中的群主二维码加入讨论群，添加时请注明硬件敏捷开发和验证方法学研讨。</p>
-<p><img src="${t}" alt="图片"></p>`;export{e as assetURLs,r as default,n as metadata,s as toc};
+<p><img src="${t}" alt="图片"></p>`;export{e as assetURLs,l as default,n as metadata,s as toc};

zh-cn/assets/index-bccae718.js → zh-cn/assets/index-0850e6f5.js

@@ -1,4 +1,4 @@
-const p="/zh-cn/assets/image1-f1a8209b.jpg",o="/zh-cn/assets/image2-f5de5635.jpg",t=[p,o],l={label:"喷泉码浅谈",description:"喷泉码（Fountain Code）是一种在无线通信、数据传输和网络编码领域中使用的错误纠正技术。它与传统的纠错码和编码方法有所不同，喷泉码被设计用于在不确定信道条件下的高效数据传输。",location:"新疆",author:["施继成"],tags:["RDMA"],date:"2023-08-31",title:"Fountain Code"},a=[{label:"喷泉码简介",level:2},{label:"LT 编码",level:2},{label:"Raptor 算法",level:2},{label:"总结",level:2}],r=`<h2 id="喷泉码简介">喷泉码简介</h2>
+const o="/zh-cn/assets/image1-f1a8209b.jpg",p="/zh-cn/assets/image2-f5de5635.jpg",t=[o,p],l={label:"喷泉码浅谈",description:"喷泉码（Fountain Code）是一种在无线通信、数据传输和网络编码领域中使用的错误纠正技术。它与传统的纠错码和编码方法有所不同，喷泉码被设计用于在不确定信道条件下的高效数据传输。",location:"新疆",author:["施继成"],tags:["RDMA"],date:"2023-08-31",title:"Fountain Code"},a=[{label:"喷泉码简介",level:2},{label:"LT 编码",level:2},{label:"Raptor 算法",level:2},{label:"总结",level:2}],r=`<h2 id="喷泉码简介">喷泉码简介</h2>
 <p>**喷泉码（Fountain Code）**是一种在无线通信、数据传输和网络编码领域中使用的错误纠正技术。它与传统的纠错码和编码方法有所不同，喷泉码被设计用于在不确定信道条件下的高效数据传输。</p>
 <p>传统的纠错码（如海明码、RS 码等）通常需要在发送方对数据进行编码，接收方则使用相同的编码进行解码和纠错。这些方法一般具有固定的码率（Code Rate），即针对一定长度的原始数据，编码后的长度是固定的，这些方法在面对不稳定的信道或严重的信道丢失时可能效果不佳。相比之下，喷泉码通过在发送方生成随机的冗余数据，然后将其注入到原始数据中，以创造出一个“喷泉”流——相应的码率也也就不固定了。接收方可以从这个流中采样任意数量的数据包，并将它们合并以恢复原始数据。</p>
 <p>喷泉码的一种常见应用是在无线传感器网络中，其中网络节点之间的通信可能受到弱信号、干扰和多径传播等因素的影响。通过使用喷泉码，节点可以在较差的通信条件下实现可靠的数据传输。</p>
@@ -30,9 +30,9 @@ const p="/zh-cn/assets/image1-f1a8209b.jpg",o="/zh-cn/assets/image2-f5de5635.jpg
 <p>上述所说的局限性是受到信息论的约束的，无法进一步降低。那么我们有没有办法实现一种方式来降低计算资源的消耗呢？比如我们如果不需要恢复出全部的原始数据呢？受到这个思路的启发 Raptor 算法应运而生。</p>
 <h2 id="raptor-算法">Raptor 算法</h2>
 <p>Raptor 本质上是一类混合编码方式，结合 LT 编码和 LDPC 编码，同时获取了两种编码的好处。如下图所示：</p>
-<p><img src="${p}" alt="图片"></p>
-<p>Raptor 编码首先通过 LDPC 编码进行一次固定码率编码，形成一个中间编码层，然后再对该编码层进行 LT 编码，生成最终的编码数据块。当然 Raptor 编码也会有其他变种，不过原理大同小异，例如下图所示：</p>
 <p><img src="${o}" alt="图片"></p>
+<p>Raptor 编码首先通过 LDPC 编码进行一次固定码率编码，形成一个中间编码层，然后再对该编码层进行 LT 编码，生成最终的编码数据块。当然 Raptor 编码也会有其他变种，不过原理大同小异，例如下图所示：</p>
+<p><img src="${p}" alt="图片"></p>
 <p>该编码具有<strong>三层结构</strong>，中间编码结果经过了两层固定码率编码，分别是 <strong>Hamming 编码</strong>和 <strong>LDPC 编码</strong>，然后再进行 <strong>LT 编码</strong>生成最终的编码块。</p>
 <p>针对 Raptor 编码的解码方式一般有两种。第一种和编码方式完全相反，首先利用 LT 编码的解码方式恢复出部分的中间编码块，然后利用固定编码的解码方式恢复出原始的数据块。第二种方式则是将上述所有的多层编码方式都变成一种矩阵运算，针对收到数据后利用矩阵的高斯消元方法解出原始的数据块。</p>
 <p>现有为人所熟知的 Raptor 编码主要有 RFC 5053 和 RFC 6330 RaptorQ 编码。两者的实现细节有诸多区别，但是内在的思路和上述的方法是类似的，有兴趣的读者可以进一步进行阅读和学习。</p>

zh-cn/assets/index-93097ad1.js → zh-cn/assets/index-148365b0.js

@@ -1,4 +1,4 @@
-const i="/zh-cn/assets/cover-6865ae02.png",e=[i],l={label:"Xline v0.4.1：一个用于元数据管理的分布式KV存储",description:"Xline是一个基于Curp协议的，用于管理元数据的分布式KV存储。现有的分布式KV存储大多采用Raft共识协议，需要两次RTT才能完成一次请求。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。",cover:"./cover.png",location:"中国香港",author:["达坦科技"],tags:["Xline"],date:"2023-06-21",title:"Xline v0.4.1: A distributed KV store for metadata management"},t=[{label:"Xline 是什么？我们为什么要做 Xline？",level:2},{label:"V0.4.0 版本有什么新功能？",level:3},{label:"欢迎参与到 Xline 项目中",level:2},{label:"相关链接",level:2}],s=`<p><img src="${i}" alt="封面"></p>
+const e="/zh-cn/assets/cover-6865ae02.png",i=[e],l={label:"Xline v0.4.1：一个用于元数据管理的分布式KV存储",description:"Xline是一个基于Curp协议的，用于管理元数据的分布式KV存储。现有的分布式KV存储大多采用Raft共识协议，需要两次RTT才能完成一次请求。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。",cover:"./cover.png",location:"中国香港",author:["达坦科技"],tags:["Xline"],date:"2023-06-21",title:"Xline v0.4.1: A distributed KV store for metadata management"},t=[{label:"Xline 是什么？我们为什么要做 Xline？",level:2},{label:"V0.4.0 版本有什么新功能？",level:3},{label:"欢迎参与到 Xline 项目中",level:2},{label:"相关链接",level:2}],s=`<p><img src="${e}" alt="封面"></p>
 <h2 id="xline-是什么？我们为什么要做-xline？">Xline 是什么？我们为什么要做 Xline？</h2>
 <p><strong>Xline 是一个基于 Curp 协议的，用于管理元数据的分布式 KV 存储。</strong> 现有的分布式 KV 存储大多采用 Raft 共识协议，需要两次 RTT 才能完成一次请求。当部署在单个数据中心时，节点之间的延迟较低，因此不会对性能产生大的影响。</p>
 <p>但是，当跨数据中心部署时，节点之间的延迟可能是几十或几百毫秒，此时 Raft 协议将成为性能瓶颈。Curp 协议就是为了解决这个问题而设计的。它可以在命令不冲突的情况下减少一个 RTT，从而提高性能。因此，<strong>Xline 旨在实现高性能的数据访问和跨数据中心场景下的强一致性。</strong></p>
@@ -43,4 +43,4 @@ const i="/zh-cn/assets/cover-6865ae02.png",e=[i],l={label:"Xline v0.4.1：一个
 <li>Curp 相关文章:<br>
 <a href="https://medium.com/@datenlord/curp-revisit-the-consensus-protocol-384464be1600">https://medium.com/@datenlord/curp-revisit-the-consensus-protocol-384464be1600</a></li>
 <li>Xline 官网：<a href="http://www.xline.cloud">www.xline.cloud</a></li>
-</ul>`;export{e as assetURLs,s as default,l as metadata,t as toc};
+</ul>`;export{i as assetURLs,s as default,l as metadata,t as toc};

zh-cn/assets/index-0a77c99b.js → zh-cn/assets/index-192ae9c1.js

@@ -1,4 +1,4 @@
-const s="/zh-cn/assets/cover-48216986.png",t="/zh-cn/assets/image1-02771bf0.jpg",n="/zh-cn/assets/image1-f46bfcc6.jpg",o=[s,t,n],p={label:"当RDMA遇到Rust",description:"2022年8月5日-6日，一年一度的中国开源基础设施活动日（OpenInfra Days China）即将在线上举行。本次会议没有限定一个统一的主题，主要聚焦云计算基础设施、云原生技术与应用实践、开源治理、5G、算力网络与边缘计算五大主题方向。",cover:"./cover.png",location:"新加坡",date:"2022-08-04",title:"When RDMA meets Rust"},r=[],e=`<p><img src="${s}" alt="封面"></p>
+const s="/zh-cn/assets/cover-48216986.png",t="/zh-cn/assets/image1-02771bf0.jpg",n="/zh-cn/assets/image1-f46bfcc6.jpg",r=[s,t,n],o={label:"当RDMA遇到Rust",description:"2022年8月5日-6日，一年一度的中国开源基础设施活动日（OpenInfra Days China）即将在线上举行。本次会议没有限定一个统一的主题，主要聚焦云计算基础设施、云原生技术与应用实践、开源治理、5G、算力网络与边缘计算五大主题方向。",cover:"./cover.png",location:"新加坡",date:"2022-08-04",title:"When RDMA meets Rust"},p=[],a=`<p><img src="${s}" alt="封面"></p>
 <p>2022 年 8 月 5 日-6 日，**一年一度的中国开源基础设施活动日（OpenInfra Days China）**即将在线上举行。本次会议没有限定一个统一的主题，主要聚焦云计算基础设施、云原生技术与应用实践、开源治理、5G、算力网络与边缘计算五大主题方向。</p>
 <p><strong>云计算基础设施分论坛</strong>主要聚焦云计算基础设施领域的前沿技术和优秀实践，围绕多硬件架构和多操作系统支持、人工智能技术应用、网络与存储，数据处理 DPU 及其他加速硬件、硬件自动化和智能运维等方面展开技术分享和探讨。达坦科技联合创始人施继成将在这一分论坛做题为<strong>当 RDMA 遇到 Rust</strong> 的专题分享。</p>
 <p><img src="${t}" alt="图片"></p>
@@ -10,4 +10,4 @@ const s="/zh-cn/assets/cover-48216986.png",t="/zh-cn/assets/image1-02771bf0.jpg"
 <h4>参会方式</h4>
 <p>想要了解更多达坦科技为什么选择 Rust 做 RDMA 库，以及开发设计背后的理念、逻辑、和实践经验，欢迎扫描海报二维码，免费注册报名。</p>
 <p>有意加入 <strong>Rust 前沿交流讨论群</strong>，请添加小助手微信：</p>
-<p><img src="${n}" alt="图片"></p>`;export{o as assetURLs,e as default,p as metadata,r as toc};
+<p><img src="${n}" alt="图片"></p>`;export{r as assetURLs,a as default,o as metadata,p as toc};

zh-cn/assets/index-8c16a843.js → zh-cn/assets/index-1ea2a101.js

@@ -1,4 +1,4 @@
-const e="/zh-cn/assets/image1-145af1bc.png",a="/zh-cn/assets/image2-b5b0ee19.png",l="/zh-cn/assets/image3-204919ac.png",p="/zh-cn/assets/image4-e50f112d.png",t="/zh-cn/assets/image5-cdb8d1de.png",i=[e,a,l,p,t],o={label:"数据库隔离级别及MVCC",description:"数据库在同时处理多个事务时需要决定事务之间能否看到对方的修改，能看到多少等等。根据隔离的严格程度，从严到松可以分为 Serializable, Repeatable reads, Read committed, Read uncommitted。我们用下面这个 KV 存储的例子来解释这四个隔离级别。KV 存储的初始状态如下：",location:"中国香港",tags:["Xline"],date:"2023-02-16",title:"Database isolation level and MVCC"},n=[{label:"数据库隔离级别介绍",level:2},{label:"Read uncommitted",level:3},{label:"Repeatable read",level:3},{label:"Serializable",level:3},{label:"Snapshot 隔离级别及 MVCC",level:2},{label:"一点联想",level:2},{label:"总结",level:2}],s=`<h2 id="数据库隔离级别介绍">数据库隔离级别介绍</h2>
+const e="/zh-cn/assets/image1-145af1bc.png",a="/zh-cn/assets/image2-b5b0ee19.png",p="/zh-cn/assets/image3-204919ac.png",l="/zh-cn/assets/image4-e50f112d.png",t="/zh-cn/assets/image5-cdb8d1de.png",i=[e,a,p,l,t],o={label:"数据库隔离级别及MVCC",description:"数据库在同时处理多个事务时需要决定事务之间能否看到对方的修改，能看到多少等等。根据隔离的严格程度，从严到松可以分为 Serializable, Repeatable reads, Read committed, Read uncommitted。我们用下面这个 KV 存储的例子来解释这四个隔离级别。KV 存储的初始状态如下：",location:"中国香港",tags:["Xline"],date:"2023-02-16",title:"Database isolation level and MVCC"},n=[{label:"数据库隔离级别介绍",level:2},{label:"Read uncommitted",level:3},{label:"Repeatable read",level:3},{label:"Serializable",level:3},{label:"Snapshot 隔离级别及 MVCC",level:2},{label:"一点联想",level:2},{label:"总结",level:2}],s=`<h2 id="数据库隔离级别介绍">数据库隔离级别介绍</h2>
 <p>数据库在同时处理多个事务时需要决定事务之间能否看到对方的修改，能看到多少等等。根据隔离的严格程度，从严到松可以分为 Serializable, Repeatable reads, Read committed, Read uncommitted。我们用下面这个 KV 存储的例子来解释这四个隔离级别。KV 存储的初始状态如下：</p>
 <p>Table 1:</p>
 <p><img src="${e}" alt="图片"></p>
@@ -8,12 +8,12 @@ const e="/zh-cn/assets/image1-145af1bc.png",a="/zh-cn/assets/image2-b5b0ee19.png
 <p><img src="${a}" alt="图片"></p>
 <p>在 Read uncommitted 的隔离级别中，多个同时执行的事务是能够互相看到互相没有 commit 的写操作，因此可以认为这种隔离级别几乎没有作用。在上述例子中，Operation 2 读到的内容是 “AA”，Operation 4 读到的内容则是“DD”，即使第二个事务最终 Rollback 了。Read committed 有两个事务同时被执行，自上而下是执行顺序。</p>
 <p>Table 3:</p>
-<p><img src="${l}" alt="图片"></p>
+<p><img src="${p}" alt="图片"></p>
 <p>在 Read committed 的隔离级别中，只有被 Commit 后的结果可以被看到，因此在 Table 2 的执行顺序中，Operation 2 和 4 都能够读取到 “AA” 的值，即 Key 1 的值没有改变。如果按照 Table 3 中的情况执行两个事务，Operation 2 读到的值为 “AA”，Operation 5 读到的值为 “DD”，因为此时事务 2 已经执行成功。</p>
 <h3 id="repeatable-read">Repeatable read</h3>
 <p>如果在 Table 3 中的事务 1 两次连续读操作，用户想要保证读到相同的值，那就需要使用 repeatable read 隔离级别。在这个隔离级别中，在同一个事务中对同一条数据的多次读取保证会得到相同的值，即使这个过程中该数据被其他已经提交的事务修改掉。当然该隔离级别也有一些情况无法保证隔离性，比如下列情况：</p>
 <p>Table 4:</p>
-<p><img src="${p}" alt="图片"></p>
+<p><img src="${l}" alt="图片"></p>
 <p>在 repeatable read 的隔离级别下，Operation 2 的返回结果是 ["CC"] —— 只有 Key 3 的值被返回了，但是 Operation 5 的返回值是 ["CC", "DD"]。总结一下，repeatable read 的隔离级别仍然无法很好处理涉及多条数据的情况，特别是当有新的数据插入或者删除的情况。</p>
 <h3 id="serializable">Serializable</h3>
 <p>最严格的隔离级别叫做 Serializable，这个级别的定义也是最清晰明了的，在这种隔离级别下的执行结果，就“仿佛”是将所有事务串行起来一条一条执行的结果。上面这句话中值得强调的是 “仿佛” 二字，为了提高性能，几乎没有数据库是采用真正物理意义上的串行执行来保证 Serializable 的，仅仅达到类似效果即可，实现的方法是可以多种多样的。在 Serializable 级别下还有一个细致的分类，叫做 Snapshot，该分类与 Serializable 类似但约束能力上稍弱。正是因为 Snapshot 在约束上的放松，使得其实现起来具有更好的性能，也是绝大多数数据库默认支持的隔离级别。下面我们就来说说 Snapshot，以及引申出来的 MVCC 实现方法。</p>