codeck

成功在树莓派上运行恒星节点

Sat, 25 Jun 2016 07:56:01 +0000

恒星网络是新一代去中心化分布式账本，在比特币和瑞波的基础上做了的很多改进，其中一项就是运行节点的资源需求非常低。所以一直有在树莓派上运行恒星节点的想法。

64bit！64bit？

之前有运行stellar-core的经验，知道它需要64位的time_t。所以在树莓派3发布时很期待，因为第一次集成了64位处理器。但进一步调研发现官方系统仍然是32位，社区在尝试64位模式，其中有日本网友制作了64位docker环境，看上去和移植stellar-core需要的基础已经非常接近。但考虑到这个方式64位host系统还不稳定，而且arm64的docker镜像也没有经过足够测试，不知道还有多少坑，所以一直没有下决定订购。同样因为对社区成熟度的担心，原生64位支持的PINE64也仅是关注没有实操。

Rasberry Pi Model B (2013)

直到上星期，从回收来的显卡挖矿机零件中里找出一个树莓派，还是2013年底全民挖矿时的配置，当时用做矿机的看门狗，负责死机后充启。综合外观和年份，确定应该是第一代Model B，配置有ARMv6 (32-bit)的BCM2835处理器和512M内存，存储为4G SD卡。

拿着这个小设备的时候突然冒出一个想法，我们知道32位平台上处理int64_t是没有问题的，编译器能够转化为32位操作模拟。那有没有可能通过软件模拟出64位time_t呢，很快看到google的结果是不能。但同时看到这个结果：NetBSD下time_t都是64位啦！

NetBSD Is the Key

于是从这里找到NetBSD 7.0的镜像，装到SD卡，开机，用root登入，安装pkgin。因为evbarm编译好的二进制包中只有4.8版本的gcc，不满足stellar-core最低4.9的要求，花费数天试图通过pkgsrc交叉编译出evbarm上可用的gcc5不成功之后，选择使用clang。安装过程如下：

# @netbsd/arm
export PKG_PATH=http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv6hf/7.0_HEAD/All
pkg_add pkgin
pkgin install git libtool-base pkg-config automake gmake bison flex pandoc clang

但clang仍然使用系统自带的libstdc++ 4.8版本，不符合stellar-core的要求。于是决定构建libc++库以支持stellar－core需要的c++11特性。3.7版本libc++需要cmake 3.5版本，而给evbarm编译好的二进制包中只有3.4版本。这些依赖软件如果直接在树莓派上编译将耗费大量的时间，所以首先按照 https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/doc/HOWTO-use-crosscompile 中的指导，本地安装一个NetBSD7的系统，并配置交叉编译环境(非root方式)。

# @netbsd/x64
wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0.1/source/sets/gnusrc.tgz
wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0.1/source/sets/sharesrc.tgz
wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0.1/source/sets/src.tgz
wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0.1/source/sets/syssrc.tgz

for file in *.tgz
do
    tar xfz $file
done

wget ftp://ftp.netbsd.org/pub/pkgsrc/stable/pkgsrc.tar.xz
tar --xz -xf pkgsrc.tar.xz -C usr

cd usr/src && ./build.sh -U -u -m evbarm -a earmv6hf tools distribution
cd ~/usr/pkgsrc/bootstrap && ./bootstrap  --prefix=~/usr/pkg --unprivileged

构造出工具链并完成pkgsrc自举之后，修改~usr/pkg/etc/mk.conf为:

# @netbsd/x64
# Example /home/rpi/usr/pkg/etc/mk.conf file produced by bootstrap-pkgsrc
# Wed Jun 15 08:24:20 UTC 2016

.ifdef BSD_PKG_MK       # begin pkgsrc settings

#ABI=                   64

UNPRIVILEGED=           yes
PKG_DBDIR=              /home/rpi/usr/pkg/var/db/pkg
LOCALBASE=              /home/rpi/usr/pkg
VARBASE=                /home/rpi/usr/pkg/var
PKG_TOOLS_BIN=          /home/rpi/usr/pkg/sbin
PKGINFODIR=             info
PKGMANDIR=              man


.endif                  # end pkgsrc settings

USE_CROSS_COMPILE?=  yes
CROSSBASE=           ${LOCALBASE}/cross-${TARGET_ARCH:U${MACHINE_ARCH}}
.if !empty(USE_CROSS_COMPILE:M[yY][eE][sS])
MACHINE = evbarm
MACHINE_ARCH=        earmv6hf
TOOLDIR=             /home/rpi/usr/src/obj/tooldir.NetBSD-7.0.1-amd64
CROSS_DESTDIR=       /home/rpi/usr/src/obj/destdir.evbarm
PACKAGES=            ${PKGSRCDIR}/packages.${MACHINE_ARCH}
WRKDIR_BASENAME=     work.${MACHINE_ARCH}
.endif

然后构造cmake以及相关依赖项目，

# @netbsd/x64
export PATH=~/usr/pkg/bin/:~/usr/pkg/sbin:$PATH
cd ~/usr/pkgsrc/devel/cmake && bmake package

将构造出的软件包从~/usr/pkgsrc/packages.earmv6hf/All目录复制到树莓派并安装.然后在树莓派中签出并构建libc++

# netbsd/arm
export PATH=~/usr/pkg/bin/:~/usr/pkg/sbin:$PATH
svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_370/final  llvm37
cd llvm/projects
svn co http://llvm.org/svn/llvm-project/compiler-rt/tags/RELEASE_370/final compiler-rt
svn co http://llvm.org/svn/llvm-project/libcxxabi/tags/RELEASE_370/final libcxxabi
svn co http://llvm.org/svn/llvm-project/libcxx/tags/RELEASE_370/final libcxx
svn co http://llvm.org/svn/llvm-project/libunwind/tags/RELEASE_370/final libunwind
cd ../../ && mkdir libcxx-build && cd libcxx-build && CXX=/usr/pkg/bin/clang++ CC=/usr/pkg/bin/clang cmake -G "Unix Makefiles" ../llvm/
make cxx

构建libc++成功后，就完成了stellar-core需要的环境准备。按照常规步骤，

#nerbsd/arm
git clone https://github.com/stellar/stellar-core.git
cd stellar-core
./autogen.sh
./configure --disable-postgres CC=clang CXX=clang++ CXXFLAGS="-I/home/rpi/libcxx-build/include -I/home/rpi/libcxx-build/include/c++/v1 -L/home/rpi/libcxx-build/lib -stdlib=libc++"
LD_LIBRARY_PATH=/home/rpi/libcxx-build/lib/ gmake

成功构建stellar-core之后，通过

# @netbsd/arm
LD_LIBRARY_PATH=/home/rpi/libcxx-build/lib/ stellar-core

运行成功。

Crash!

构建出stellar－core后，发现经常突然退出，于是通过

ktruss -t s -p <stellar-core-pid>

观察到退出时总是显示，

...
24049 2 stellar-core SIGCHLD caught handler=0x3cc9d0 mask=0x0 code=0x0
24049 2 stellar-core SIGPIPE SIG_DFL

发现是SIGPIPE导致的退出，进一步排查发现 4b4eb669 中所需要的修改，修改后stellar-core不再异常退出。

Pull Requests

代码在NetBSD环境下需要的一些改动，已经提交：

Last but Most Important

最重要的是广告时间：

"GDPJ4DPPFEIP2YTSQNOKT7NMLPKU2FFVOEIJMG36RCMBWBUR4GTXLL57 nezha"

敬请各路英雄将本节点加入QUORUM_SET，小哪吒是正直的！

恒星共识协议-3

Thu, 07 May 2015 00:00:00 +0000

联邦拜占庭共识

本节介绍联邦拜占庭一致性模型(FBA)。和其他非联盟一致性相同，FBA处理副本状态，如交易总帐或者认证树，的更新问题。通过对应用哪些些更新达成一致，众节点避免矛盾不相容的状态。我们给每一个更新确定唯一的槽，以此可以推断更新之间的依赖关系。比如，槽可以是一系列应用记录中连续计数的位置。

一个ＦＢＡ系统运行共识协议保证众节点认可一致的槽内容。一个节点 $v$ 当它安全的应用了可以安全的应用槽 $i$ 中的更新 $x$

恒星共识协议-2

Thu, 07 May 2015 00:00:00 +0000

机制	去中性化控制	低延时	灵活信任	渐进安全
工作量证明	✓
权益证明	✓	maybe
拜占庭一致性		✓	✓	✓
Tendermint	✓	✓		✓
SCP(本文)	✓	✓	✓	✓

恒星共识协议-1

Tue, 05 May 2015 00:00:00 +0000

恒星共识协议：
互联网级共识的联邦模型

David Mazières (恒星发展基金会)

摘要

本文介绍联邦占庭一致性(FBA)，一个达成共识的新途径。FBA的健壮性源自法定人数切分，既由共同确定系统级法定人数的每一个节点所做出的独立信任决定。这些切分结合成系统非常类似目前各独立网络独立的对等直连及转发决定联合成互联网的方式。

我们还提出恒星共识协议(SCP)，一个FBA的构造方法。和所有拜占庭一致性协议一样，SCP不做任何关于攻击者理性行为的假设。和之前拜占庭一致性模型不同，它们预设一个全局一致接受的成员名单，而SCP具有促进网络有机增长的开放式成员资格。和分布式的工作量证明(PoW)及权益证明(PoS)比较，SCP的计算和财务需求适度，降低进入门槛并且潜在地把金融系统开放给新参与者。

介绍

金融基础设施现在是一大堆封闭系统。这些系统的差异造成交易费用高企和金钱跨政治和地理边界转移缓慢。这种摩擦限制了金融服务发展，同时使数十亿人所受金融服务不足。

为了解决这些问题，我们需要一个支持互联网所见到那种有机增长和创新的金融设施，但仍保持金融交易的诚信原则。历史上我们依赖于高进入门槛保证诚信。我们相信老牌的金融机构并尽我们所能去监管它们。但这种排他性和有机增长目标矛盾。增长需要新的创新性参与者，他们可能只拥有不多的财务和计算资源。

我们需要一个向任何人开放的世界性金融网络，以致新参与者可以加入并扩展受服不足社群的金融渠道。此网络的挑战是确保参与者准确记录交易。鉴于低进入门槛，用户不会相信商家能自我监管。鉴于范围遍及全世界，商家也不全会相信单独实体来运营此网络。有个令人信服的选择是一个参与者们通过认可他人交易的有效性来共同确保完整性的分布式系统。这种一致性取决于有个世界性共识的机制。

本文提出联盟拜占庭一致性(FBA)，一个适用于世界性共识的模型。FBA中，每个参与者了解它认为重要的其他人。任何交易它认为已结算之前，将等待其他人中的绝大多数认可该交易。相应的，那些重要的参与者会不认可这个交易，除非有他们认为重要的其他参与者也认可，以此类推。最终网络中足够人接受一个交易它不能撤回。直到那时任何参与者认为此交易被结算。FBA的共识可以确保一个金融网络的完整性。它的分布式控制可以激励有机增长。

本文进一步提出恒星共识协议(SCP), 一个FBA的构造方法。我们证明SCP的安全性对于一个保证任何节点故障场景中一致性的异步协议是最优的。我们还展示除非参与者故障使得信任依赖无法满足, 否则SCP不受阻停状态限制，在这些状态中不再可能有共识。SCP是第一个同时满足四个关键属性的被证明安全的共识机制：

分布式控制。 任何人都可以参与，没有共识需要其认可的中心权威作决定。
低延时。 实践中，节点可以在人们对web或者支付交易所期待的时间跨度（也就是说最多几秒）内达成共识，
灵活信任。 用户信任任何他们所见之组合的自由。特别，一个小的非营利可能在保证大组织诚实方面充当重要角色。
渐进安全。 安全性取决于数字签名和哈希函数族，其参数被切实调整到对抗具有无法想像巨大计算能力的对手。

SCP在金融市场外也有确保组织诚实履行关键职能的应用。一个好例子是认证中心(CAs)，不夸张地说他们保存web的钥匙。经验显示CAs签名不正确的认证被用作不法用途。一些提议通过认证透明性解决这个问题。SCP可以增强认证透明性：不只是任何人都可以简单的审计CA行为，审计者还可以只认可所有已颁发的认证中的一部分，这使得骗取或者变造之前颁发的认证而不被发现变得困难。

下一节讨论以往的共识方式。第三节定义联邦拜占庭一致性和讲解一个系统希望达到的安全性和存活性。第四节讨论FBA系统中的最佳故障恢复，由此引出SCP我们希望达到的安全性。第五节构建联邦配置中保证共识所需要的工具。第六节展示SCP自身，而且证明它的安全性以及满足依赖性的节点中不存在阻停状态。第七节讨论SCP的限制。最后第八节汇总结论。对于不了解数学记号的读者，附录A定义了文中使用的一些符号。

试谈拖延症及如何有效GTD

Tue, 28 Apr 2015 00:00:00 +0000

作为拖延症重度患者，十多年来屡战屡败，陷入拖延-焦虑的恶性循环越来越深。不曾弃疗，这是又一次寻找病源的努力。

从自己经历看，拖延症典型症状就是主要工作目标不能如期完成，其过程几乎都是在一些细致末节上花费了大量的时间。有人说拖延是没有时间观念，或者缺乏大局观，也有说是自控力差，或者是懒惰，不自信或者是逃避焦虑，更有意思的是既有人说是害怕失败，也有人说是害怕成功。当然很多病友更愿意接受的是完美主义者的过高自我要求导致拖延。知乎上对这个的讨论有很干货。

只看前头的分析，拖延患者怎么都像是上帝造人产生的次品、社会的累赘，可实际上好多人自述被拖延的往往是书稿、博士论文、原创项目、重要决策等，与严重心理缺陷的观点恰恰相反。

病久成医的我认为拖延的根源，是过量并行任务间复杂关系造成的分析和规划过载。通过一个分析和规划需求不断膨胀的过程来进行说明：

纠结之路

分而治之

完成一项工作的方法，通常步骤就是分解任务，逐个解决。Emacs orgmode提供了这类方式的支持。在GTD我们通常这么记录：

任务
- 子任务甲
- 子任务乙

子任务甲乙之间没有依赖，并行存在。

统筹协调

因为需要完成的任务复杂，通常需要继续分解，然后就遇到不同任务之间共享的子任务的情况：

任务
- 子任务甲
  - 子任务甲一
  - 子任务甲二
    - 子任务甲二甲
    - { } 子任务甲二乙
- 子任务乙
  - 子任务乙一
  - { } 子任务乙二 (=子任务甲二乙)

子任务甲二乙和子任务乙二实际上是相同任务，任何一个完成另一个也完成。

预备方案

通常完成任务目标的方法不止一个，我们称为捷径：

子任务甲一
- 子任务甲一甲
- 子任务甲一乙
- ( ) 捷径甲一丙
- ( ) 捷径甲一丁

(子任务甲一甲+子任务甲一乙)/捷径甲一丙/捷径甲一丁中任何一个完成，都能完成子任务甲一的目标。

风险管理

捷径和主要方案的区别在于存在较高的不确定性：

( ) 捷径甲一丙
- 子任务甲一丙一
- 子任务甲一丙二
- < > 风险甲一丙三

风险甲一丙三依赖外部条件，存在一定概率使捷径甲一丙无法达成。

拥抱变化

任务进行过程中，子任务可能反向衍生成新的任务，如：

任务
- 子任务甲
  - 子任务甲一
  - 子任务甲二
    - 子任务甲二甲
    - { } 子任务甲二乙
- 子任务乙
  - { } 子任务乙一
  - { } 子任务乙二 (=子任务甲二乙)
- 新任务/里程碑丁
  - { } 子任务丁一 (=子任务乙一)
  - { } …
  - 子任务丁二

新任务和里程碑没有本质区别，实际上，里程碑本身是一个待完成的任务，而任何一个新项目/任务，都可以理解成更大范围（比如超越项目考虑职业生涯，甚至人生）的里程碑。

传统智慧

如果考虑到大脑的分析规划，是对各种外部不确定性和任务目标的重要性进行评估，并把这些评估代入任务关系，试图找到最优方案的过程。以上各种情况，对分析规划的（计算）要求，显然是层层递进的。以人类大脑目前进化水平，如果试图以这种方式完成决策，很容易就陷入到分析过载中。拖延症很多发生在把知识加工过程，知识加工也要占用分析中枢(规划可以理解为特殊的知识加工)，更加重了规划困难。在分析过载后，规划中枢仍然要持续输出规划结果，必然需要排除造成过载的这部分载荷，表现出来就是逃避焦虑，而输出的结果也是偏好即时满足的。这就好像装备重机枪的现代战士，在枪支卡壳之后只能掏出匕首作战，甚至不如古人大刀长矛的战斗力。冷兵器时代有很多传世的武功，面对分析过载的方法通常被称为人生智慧也有很多流传。从著名的“专注当下”，”抓大放小”，到OODA循环和各种时间管理，甚至赤裸裸的“接受不完美”，都是以牺牲精度的代价，保护有限的规划能力达到尽可能好的执行效果。

未来之道

描述任务关系是基于知识，评估外部不确定性和任务目标重要性更依赖于经验和直觉。规划中考虑更多的任务分解、任务关联等关系，本身是一个追求理性的过程，或者简单的说更“科学”。看到很多轻度拖延症患者在人(xin)生(ling)智(ji)慧(tang)的引导下症状能够缓解，但我这样的重度拖延症患者的极端理性倾向，任何近似都会激发对方法本身有效性的评估分析，使得分析中枢更加过载，加剧自身焦虑感。所以有效的GTD应该做到两点：

不约束的接受所有输入
基于输入自动进行规划

目前了解GTD方法论鼓励第一点，但没有自动规划的功能。而GTD软件如org-mode没法接受第一部分举例的(){}<>等多种括号表示的不同任务和任务关系。但要自动规划，首先要明确人脑规划目标是什么，是过程中Effort-Goal曲线的平滑？还是考虑到考虑到风险的收益期望最大？风险收益评估本身的不准确性如何考虑（可能估算误差会导致规划结果的不同，类似物理中的相变）？这些需要进一步思考。

另外关于极端理性倾向的来源，我认为是对世界认识的倾向于变化，所以对现象更好奇。记忆大量现象需要寻找现象间更多关联进行压缩，导致寻找深度关联的习惯，也就是理性的来源。这个同时加剧了关联的输入，和分析精度的苛刻。

总算写完了。最后我会说，写这篇Blog拖延了原定开发计划三天时间吗？

解决开发停滞
- 整理开发计划
  - 寻找GTD工具
    - {x} 了解org-mode的TODO依赖
      - 记录orgmode任务依赖的不足
写关于GTD的文章
- {x} 记录orgmode任务依赖的不足
- 其它95%的写作工作…

解决了VirtualBox升级到最新版以后闪断的问题

Mon, 27 Apr 2015 03:05:19 +0000

VirtualBox升级到最新版(4.3.26)以后，ssh总是断开连接，最频繁的时候几分钟就断开一次。搜索一下，发现这两个链接

https://www.virtualbox.org/ticket/13839
https://www.virtualbox.org/ticket/12441

描述的问题接近。先查看一下虚拟机日志VBox.log，每次断连时间点都有这几条日志：

01:31.993782 NAT: link down
01:36.993530 NAT: link up
01:36.998519 NAT: DNS#0: 223.5.5.5
01:36.998543 NAT: DNS#1: 223.6.6.6
01:36.998758 NAT: set redirect TCP host 0.0.0.0:22 => guest 10.0.2.15:22

对照VBoxSVC.log里，这条日志也频繁出现：

39:56:33.359581 dns-monitor HostDnsMonitorProxy::notify

因为VirtualBox记录日志是相对时间，叠加计算后，两条日志接近相同时间。按照前面链接里的建议，关机执行

C:\>VBoxManage.exe modifyvm “myvm” –natdnshostresolver1 on

再启动虚拟机后断连问题彻底解决。

你好，世界

Mon, 13 May 2013 00:00:00 +0000

我的第一篇文章,修改一下!

试试公式能不能用 $a^2 + b^2 = c^2$

再试试d3能不能用