最近买了一台Atlas 200 DK，照着使用手册用了一把，一堆的坑，我借这个例子来说明一下到底是什么是设计上的“守弱”。
Atlas 200 DK的安装说明在这个地方：https://ascend.huawei.com/doc/Atlas%20200%20DK/1.3.0.0/zh/overview，我就用这个1.3.0.0来说明这个文档（包括背后所反映的设计思路）的问题在什么地方。
在进一步介绍之前，我再次提醒一下读者，我们这里谈守弱之类的概念，都是谈“道”，不是谈“名”。我们说的是你的行为是否守弱，不是你的态度是否“装孙子”。
下面我们开始。
从文档的开头到“体验指引”，看来都还中规中矩：
说了这是个什么设备，如何组网，如何安装，逻辑链是完整的。
我能拿到的初步印象是：Atlas，作为一个盒子，开发需要一台PC工作站。该工作站上，必须安装Ubuntu 16.04和Mind Studio，Atlas上需要安装另一个系统，用SD卡启动，最后两者用USB线和网线连在一起，就可以用Whatever什么功能来进行下一步的操作了。
这从架构上说，最不友好的地方是仅支持特定版本的Ubuntu（而且是很旧的版本），但Anyway，勉强可以认为是发展初期，测试不够，以后扩展吧。但让用户为了你的工具重新安装系统，这其实拒绝很多用户的。如果是我来做这个设计，我会首先考虑把这个系统做在Docker里面。（我当下的测试的方法是直接用virt-manager安装了一个虚拟机来验证功能有没有风险，肯定是不敢拿我的工作用机来给你玩这个游戏的），但无论如何吧，这暂时还是可以接受的。
然后是“描述”部分，这个作为综述，勉强也可以接受，但其实基本上没有什么用，因为我都还不知道你具体在Atlas和Host UI上都有些啥呢，你跟我整这个模块那个模块的，这个时候引入这些信息，我都没法加到我的逻辑链中。这里就开始跳到“名”上，偏离了守弱（“我有什么就说我有什么”）的方向了，这是在“装”。但装得不那么明显，我认了。
接着往下看，开始谈怎么安装系统了，“Mind Studio工具部署”，这个应该是装在Host UI上的。但打开“简介”，你发现了一个“DDK”的介绍：
——我就要问了，我们不是一直在谈Mind Studio的吗？这个DDK是从哪里跳出来的？你介绍了DDK，一副很“专业”的样子，又是TE，又是DVPP的，还可以“通过Makefile编译相应的工程文件”？和我什么关系？我装还是不装？装在哪里？
好吧暂时我只能猜了，开发人员嘛，这种情况见多了，我就猜这是配套Mind Studio使用的另一个套件吧，我一起装。
（后来我问了开发人员。这里给一个明确的说明：Mind Studio是一个IDE，真正用来开发Altas应用的命令行工具称为DDK，配套不同的达芬奇硬件需要不同版本的DDK，所以把两者分离了）
然后来个“隐私说明”？
这个东西不是应该出现在全文的开头的么？而且里面谈的也不是什么GDPR之类的玩意儿，而是版权问题？——好吧，法务人员的世界咱不懂，也不敢问，它爱说就让它说吧，我们跳过。
接着是“环境说明”，里面有两个章节：“服务器端”和“客户端”。好了，我又开始糊涂了，前面哪里提过什么“服务器端”和“客户端”了？Altas是服务器端还是Host UI是服务器端？
你看，这种描述，如果你不用真的拿他操作，说明得其实都挺“高大上”的样子的，但你要正经用呢，全它么瞎扯淡。我反复说：装样子很容易，做设计很困难，就这个意思。
你说开发人员能否用得了这个单板呢？肯定是可以的，但他们写的手册有没有告诉你怎么用呢？肯定是没有的。这个手册很大程度上给开发人员的领导和客户的领导看的——他们不用操作，他们是在“名”上的：这个产品有没有手册啊？手册写得是否“专业”呀？这两个问题搞定了，“名”就有了，而具体能不能用呢？那个东西“无名”——至少在应用的工程师介入前“无名”。
很多工程师觉得：只要我自己用着能跑，这个事情的根本就有了，所以没有写出来，只是没有写出来而已，无关大局。还能在不会用的小妹妹面前装个B。但你要搞清楚：用户手册其实就是架构，因为用户是根据你的表述（作为承诺）来实施他的方案的，如果你不说明什么是你的承诺，什么不是你的承诺，他就只能认为一切可见的东西都是他的依赖：Ubuntu必须是16.04的，软件是个黑盒（因为所谓服务器和客户端的概念是一团麻），只能相信最后输出的文件了。这样他的方案就会和你不贴合，本来可以优化的地方不能优化（比如本来你有一个Python就可以用的，他以为必须有Python2和3，没有的平台就不选择用你这个系统了），本来没有关系的地方又有了关系（比如Ubuntu的版本）。他的方案确定了，你后面的版本就只能和这个要求一致，这样天然产生的不能变的部分，这就形成架构了。架构不是你不定义就不产生的，但一旦架构不符合你的优势，你就万劫不复，再也不要指望翻身了。这也是我在这里（怎么看华为开卖采用deepin Linux系统的MateBook？）说的：资本可以带来水流，但如果你自己架构不稳，被冲垮了，资产的价值只是滋养别人而已。
Anyway，我告诉你，这里的服务器和客户端，根本不是指机器，它是服务端的软件和客户端的软件，都安装在HostUI上。然后mind studio是服务器，用浏览器连上去那叫客户端。换句话说，这个mind studio是个Web Server，你通过登录这个Server来使用它的功能，如此而已。（这本来是他的内部实现，不需要让你知道，他让你知道了，又不提供完整的信息。说起来根本就没有考虑过逻辑）
我们接着看服务器端环境要求：机器的版本，Ubuntu的版本要求，Python的版本要求，Java的版本要求……：
很专业的样子，对吗？其实这是个样子货——你都已经要求我的Ubuntu版本了，里面本来就带着Python，你是让我不要装Ubuntu的Python，按你的要求另装一个符合要求的版本呢？还是让我每次安装的时候确认这个Python的版本是否正确呢？实际情况是，后面的安装依赖判断Python和Java的安装目录就是Ubuntu自带的路径，你要求就是用Ubuntu的版本，然后在这里说Python的版本要求，这是在干什么？——装“专业”而已。
这里其实要求版本，是有一定的道理的，比如这套工具的提供团队仅测试过某个版本的Python上可以正常工作，但用户可能会升级Ubuntu，他怕背锅，加上这一句以后可以避免责任。这……一定程度和角度上合理吧，这种情况，守弱的做法是，直接说你当时测试过什么版本的Python，如果工作不正常，请用户考虑一下是否可以回退版本。但从设计来说，这完全不合理，你只能用某个版本特定时期的ubuntu，干脆你定制一个Ubuntu Image给用户算了。如果你的方案连Ubuntu的版本内升级都不能容忍，你就不要说支持某个版本的Ubuntu了。
所以，不要既想拿好处，又想不背锅，人只有一个身体，站在南边就不可能再站在北边了。否则就必然是又当又立，其中一边必然是“名”，维护一个不存在“道”背书的“名”发展，你的力量将全部耗散在这个名上。你维持一个没有道支持的名，这个名背后的道就会失去投入。因为所有人，甚至可能包括你自己，都会觉得这上面已经成功了，不需要投入了。
说完感慨，我们接着来：下一步是“配置普通用户”，WTF！这是什么？为什么要配置普通用户，配置谁的普通用户？这个用户是干什么的？
我告诉你们答案，这个就是普通的Linux用户，这个逻辑跳出来也是莫名奇妙的，难道方案提供者不知道安装Ubuntu是默认创建普通用户的吗？你让我创建普通用户，要不要让我还要配置hostname，配置ip地址，配置时区啊？这是Ubuntu的安装手册还是Mind Studio的安装手册啊？还让我创建这个用户的home目录？这个写作者到底用没有用过Ubuntu啊？疯了？
好，这里不理他。（其实不理是不行的，我得提前告诉你，他这里让你创建用户其实是这个目的：你整台机器只能有一个用户安装这个工具，因为它用了全局的资源，另一方面这个用户的home目录必须是750的权限，因为它创建了另一个用户，那个用户要访问你的Home目录，如果你权限不对，后面就会到处出错。从架构设计的角度，我只能说这个方案的权限管理一塌糊涂）
接着是“配置源”，有前面的经验，我认为这是让我配置特殊的sources.list？——结果不是，它是让你给你的用户加sudo权限——我服了，有人敢无条件让用户随便修改权限，降低系统的安全级别的？——这些人居然还参加过什么“可信计算”考试？这有一点点安全意识么？这简直是诈骗分子电话教你转钱给他的翻版啊。
配置源这里，和sources.list有关的语句是这样的：
配置Ubuntu16.04的源，源的官方地址在“/etc/apt/sources.list”文件中。
这我要你说？关键是你也没说什么呀。
接着是是“安装包获取”，好了，问题又来了，它说“如果是本地环境”，就如何如何，“如果是云环境”，又如何如何。
好嘛，“本地环境”和“云环境”这个概念又是从哪里冒出来的？
不理他，你就从本地环境那个链接里下mini_mind_studio_Ubuntu.rar，和MSpore_DDK-{version}-<uihost arch.os>-<host arch.os>-<device arch.os>.tar.gz吧。至于应该用哪个版本，你看着办吧，反正它也没说（倒是喋喋不休给你说他里面有些什么文件，我就好奇是不是他以后升级加减个文件，还来这个更新手册啊？），找个最新的应该不会有什么问题。
两个文件都要放在特定权限的目录下，手册作者再一次违反安全工作惯例，让用户用su root来工作。然后mind_studio和ddk都放进去，解压前者：
unzip mini_mind_studio_Ubuntu.rar至于为什么一个zip文件要叫rar这样的扩展名，我也懒得问。反正到此为止，我对写这个安装过程的工程师的专业水平，是没有任何信心了，对于他要求我这样来启动安装：
sudo ./add_sudo.sh username我不在虚拟机中都不敢运行这个命令。至于这个自动安装和手动安装的区别，我用完才知道的：前者是不配置env.conf，让系统自己判断参数。我觉得你用自动安装就好了，因为你可能根本就不知道env.conf的这些参数啥意思，让你配IP，这个IP用来干什么的？配了会影响什么？统统不知道，莫名其妙。
然后就是安装：
./install.sh这倒不会有什么错，启动浏览器到https://localhost:8888/，用密码Huawei123@登录：
一颈血。
这个问题我就不打算给他查了。我问开发团队，我也不想用你们的IDE，也不敢运行你们的安装程序，你们能不能单独安装DDK和SD卡？他们认为应该可以，所以后面我来说说怎么在Atlas上单独安装这两个工具。大家忘掉前面的东西，我们重新开始：
首先安装DDK，先按照他们文档上的链接下载DDK的rar包，就是MSpore_DDK开头的那个文件，解开，在任何x86 Ubuntu机器上都可以安装。安装前先安装依赖：
sudo apt-get install python python-setuptools python-numpy python-decorator python-pip
sudo apt-get install python3 python3-setuptools python3-numpy python3-decorator python3-pip用pip装这些东西应该也行的，但我没有试过。安装包中提供的脚本会自动安装这些东西，但权限没有处理好，没有root权限是搞不定的（有root权限也有问题，所以你还是别找不自在了）。
然后用普通用户权限就可以安装了：
./install.sh ~/目标目录注意了，这个目标目录其实不是ddk的目录，它会在你的目标目录下创建一个叫ddk的目录，安装在那里。但你以为它就创建这一个目录吗？——哪里有这么老实，它还会在你的home目录中创建一个ide_daemon的目录，里面有一些pem文件，应该是访问IDE的证书。不过这个危害不大，我原谅它。
要验证安装成功了没有，可以试试编译一下里面的sample工程。下面是一个例子，在ddk的sample/fasterrcnn_vgg16目录中。后面的表述我们以这个目录为基础。
首先，不要指望进去看见Makefile就make -f，没有的事。这个目录是只读的，要求拷贝出来用。
然后我们需要理解一下Makefile_main和Makefile_device是什么意思——直接说吧，我也不知道啥意思。基本上，从文件上看，Makefile_main生成主程序，Makefile_device生成.so，都是在ARM上运行的（应该是在Atlas的ARM核上运行的）。说起来既然都是生成Atlas上运行的程序，为什么要写两个Makefile？我没法理解。
为了运行这两个Makefile，你需要修改里面的三个宏：
DDK_HOME：这是DDK的安装目录。
CC_SIDE：device或者host。这其实是决定你的程序在Atlas上运行还是在HostUI那台机器上运行，device就是Atlas。这会导致目标程序链接的时候链不同的库：发请求给Atlas的server还是自己就在Atlas上发请求到本地
CC_PATTERN：ASIC或者Atlas。这个唯一的作用是选择Atlas的时候用aarch64的交叉编译器。它默认认为Atlas是是在HostUI上做交叉编译的，但如果你想直接在Atlas上编译，你得修改cc_rule.mk，自己把交叉编译修改成本地g++编译。这里注意了，小心别在定义CC_SIDE=device这样的名字后面放了多余的空格。这东西不做strip的，多了一个空格，它能给你整出rm -Rf ~/ddk/device /lib这种动作来。——你知道我为什么不敢把root权限交给它了吧？
最奇葩的是，你编译成功以后，脚本会删除所有的中间文件。所以你重新make，所有的编译过程，都要重新来一次——我就奇了怪了，这样你弄个Makefile干什么，搞成脚本不是杠杠的？
随便吧。反正至少DDK是可以用起来了。我们现在看怎么安装SD卡。
Altas里面包含了ARM的核和达芬奇的核，其中ARM核可以直接运行一个标准的Linux发行版，达芬奇的功能作为一个硬件加速器，通过这个Linux发行版下发。HostUI这边其实只是发送请求给那个Linux发行版而已。
我们制作SD卡，是给Atlas的ARM核安装Linux。按前述用户手册，官网提供了make_sd_card.sh脚本（相关文件，包括后面提到的iso，rar等，都可以从这里下：Ascend/tools）来生成这张SD卡，需要root权限，）来生成这张SD卡，这需要root权限，我是不敢运行。而且这个不能在虚拟机上运行（因为要直接操作SD卡，除非你把SD作为块设备转过去，我不想用这种方法，读者可以自己试试）。
我直接看了看那个脚本，觉得可以手工来做。下面是手工制作的原理，在我这里能正常工作，读者可以考虑参考一样的方法来完整这个制作。
先说一下原理：Atlas的Bootloader是内置的，Bootloader从SD卡第一个分区的fw目录中获得内核和其他MCU的固件，DTS等信息。加载内核后，用如下启动参数启动内核：
root=/dev/mmcblk1p1 rw rootdelay=1 syslog no_console_suspend initrd=0x880004000,200M cma=256M@0x1FC00000 log_redirect=0x1fc000@0x6fe04000 default_hugepagesz=2M reboot_reason=AP_S_COLDBOOT himntn=1010000000000000000000000000000000000000000000000000000000000000 slotid=00 boardid=004 nr_hugepages=25
它的root是/dev/mmcblk1p1，也就是SD卡上的第一个分区。所以，只要在SD卡第一个分区上安装一个标准的Ubuntu，在其中的fw目录中放上固件，就可以启动成功了。
官方脚本自动把SD卡分成三个分区（/,/var/log,/home)，其实不需要，你爱怎么分都可以，保证第一个分区是root就好了，格式官方使用ext3，其他也有可能可以，但这个取决于官方的内核怎么配置的，所以暂时我是建议不要改。但如果你拿到官方的内核，可以重新编译，可以考虑改用ext4，SD用ext4的效果是更好的。
（注：分三个区这个设计，如果你一直手工安装，是没有问题的，但官方的升级脚本是强依赖三个分区的，所以，如果你不想多事，最好还是3个分区。这其实也是一个破坏架构的行为。）
下面我们先在本地选一个目录来做rootfs，然后你爱怎么拷贝到SD卡上就行了：
先下载一个Ubuntu 16.04的ARM64版本的ISO：
wget http://old-releases.ubuntu.com/releases/16.04.3/ubuntu-16.04.3-server-arm64.isomount -o loop 把iso文件mount出来，拷贝其中的/install/filesystem.squashfs到一个地方，用unsquashfs命令把它解压到一个地方（后面我们把这个地方称为squashfs-root)，注意这需要root权限，因为squashfs-root就是一个ubuntu的小系统。下面是一个例子：
mount -o loop ubuntu-16.04.3-server-arm64.iso /mnt/ub_arm_iso
cp /mnt/ub_arm_iso/install/filesystem.squashfs ~/my-working-dir/
cd ~/my-working-dir
unsquashfs filesystem.squashfs
ls suqashfs-root/下面就是套路了，如果你对arch-linux很熟悉，这个过程和arch-linux的arch-chroot安装方法是一样的。不过我们现在要装的系统是个ARM的，这稍微要变一下：
如果你的本地工作系统就是arm64的，sudo chroot squashfs-root就行。
如果你的工作系统是x86的，你需要异构执行。先在你的本地工作系统中装一个qemu-aarch64-static，然后把这个文件(/usr/bin/qemu-aarch64-static）拷贝到squashfs-root对应的目录中（squashfs-root/usr/bin）。这样就可以直接chroot过去了（注意使用root权限），由于平台架构不同，内核会自动用misc-binary-fmt解释文件格式，调用qemu-aarch64-static来执行chroot，和你直接运行在ARM上的效果是一样的。
我们大概看看需要修改的东西：
- 修改/etc/hostname, /etc/hosts，这种基本动作不需要我教了吧。不会的话，根据你自己的本地系统抄呗。
- 设置时区，比如ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime。
- 要访问网络，需要DNS，可以先从本地拷贝一个/etc/resolv.conf过去，后面在Atlas上启动会替换的
- 修改/etc/apt/sources.list，增加源，在国内的话用华为的镜像（华为开源镜像站_软件开发服务_华为云）吧：
deb http://mirrors.huaweicloud.com/ubuntu-ports/ xenial main
deb http://mirrors.huaweicloud.com/ubuntu-ports/ xenial-security main
deb http://mirrors.huaweicloud.com/ubuntu-ports/ xenial-updates main - 现在可以干这个了：
apt-get update; apt-get dist-upgrade- 设置/etc/locale.gen，我选了en_US.UTF-8了。locale-gen生成locale，update-locale LANG=en_US.UTF-8
- passwd修改密码（其实Ubuntu是不推荐给root设密码的，但我们这是个个人设备，还只能ssh上去，还是加个保险吧）
- 加个普通用户，加上sudo权限（把这个用户加到sudo群组中即可）
- 安装依赖的软件：
apt-get install ssh zlib1g vim gcc python python3 strace
nfs-common sysstat libelf1 libpython2.7 libnuma1
dmidecode rsync- 最麻烦的一步：设置网络。
设置网络其实不麻烦，只是它不能错：Altas只有一个网口和一个USB Type-C连你的设备，那个USB也被模拟成一个网口了，只要有一个能工作，你都能ssh上去，但如果两个都不能工作，系统起没起来，你是不知道的。
两个网口的内核名分别叫eth0和usb0，根据你自己的组网要求，配置/etc/network/interfaces文件，比如这样：
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.2.100 # 我用一个少有人用的网段
netmask 255.255.255.0
gateway 192.168.2.1
auto usb0
iface usb0 inet static
address 192.168.3.100 # 不行我们用这个
netmask 255.255.255.0先拿这两个配置静态连上去，一旦可以ssh可以连上去，就什么都好办了。
基本的rootfs准备好了，直接手工拷贝到SD卡上就可以了。但只有这个rootfs是不够的，你还缺内核、华为自己的驱动。这些东西都被打包到mini_developerkit安装包里面了（又一个失败的设计决策）。
把mini_developerkit-xxxx.rar文件解开，在scripts目录中，有一个minirc_install_pre.sh脚本，里面有这么一段：
$INSTALL_CACHE_DIR/mini_developerkit/nve.bin 很明显，这里包括了内核，内置的M3的代码，devicetree定义，等等。按GPL协议，Linux的代码是需要开源的，各位不妨直接找华为商城要代码。
这些文件横七竖八第躺在那个rar的加压目录中，最后都拷贝到$FWM_DIR目录中，也就是你的squash-root/fw目录中，没有这个东西，你是起不来的。
有了这个以后呢？其实还是起不来，因为这个内核不是static的，还有很多动态模块被放到了/var/davince/driver目录中（注意了，这是在一个特殊的目录中，而不是在/lib/modules中）：
load_device_modules()
{
echo "load device modules"
ko_check /var/davinci/driver/drv_dfm.ko
ko_check /var/davinci/driver/drv_nor_flash.ko
ko_check /var/davinci/driver/drv_e2prom.ko
ko_check /var/davinci/driver/drv_pca6416.ko
echo /dev/mtd1 > /sys/module/hisi_nve/parameters/nve
ko_check /var/davinci/driver/drv_pcie.ko
ko_check /var/davinci/driver/ipc_drv.ko
ko_check /var/davinci/driver/drv_platform.ko
ko_check /var/davinci/driver/drv_devmng.ko
# ko_check /var/davinci/driver/drv_devmm.ko
ko_check /var/davinci/driver/drv_devdrv.ko
ko_check /var/davinci/driver/drv_dvpp.ko
ko_check /var/davinci/driver/drv_log.ko
ko_check /var/davinci/driver/drv_mdio.ko
ko_check /var/davinci/driver/drv_lsw.ko
ko_check /var/davinci/driver/drv_gmac.ko
ko_check /var/davinci/driver/drv_prof.ko
ko_check /var/davinci/driver/drv_aicpu.ko
ko_check /var/davinci/driver/drv_fan.ko
ko_check /var/davinci/driver/drv_pwm.ko
ko_check /var/davinci/driver/drv_spi.ko
ko_check /var/davinci/driver/tee_drv.ko
ko_check /var/davinci/driver/drv_upgrade.ko
ko_check /var/davinci/driver/hi35xx_dev_host.ko
ko_check /var/davinci/driver/mcc_drv_host.ko
ko_check /var/davinci/driver/mcc_usrdev_host.ko
echo "finish load device modules"
}然后还有一堆的ko,so文件，被散布在系统的各个角落里。这哪里是什么大厂的产品啊，这完全是一个没有学过Linux的学生把自己的系统弄乱的方式嘛。（公平一点说，这里用到的目录也有限，但它的位置缺乏规律。比如把驱动放到/var目录中，这完全不合规矩。修改rc.local这种事情是留给本地管理员的，不是给安装包的，这些行为一做，有经验的管理员就不可能信任你这个安装程序了。）
所以我也懒得再去跟踪这个实现了，我们完全按官方的脚本方式来（注：这只是根据当前的版本来表述的，以后升级不一定可以，而且这里的脚本动本地文件，我建议读者使用虚拟机运行它）：
第一步：创建一个工作目录，假设是dk_work。先下载mini_developerkit*.rar，解出里面的scripts/minirc_install_phase1.sh，把这个文件和那个mini_developerkit*.rar，一起拷贝到dk_work/opt/mini目录中。
第二步：运行安装脚本，把安装内容预装到dk_work中：
(注意，这个dk_work要求绝对路径。）第三步：把dk_work的内容（包括目录结构和权限）全部拷贝到你的squashfs-root中（squashfs-root的制作过程我前面说了，由于都在你自己的控制下，我建议不要在虚拟机中做。因为至少在我的版本中，虚拟机中靠qemu-aarch64-static做chroot，/dev/null不能正常工作）
第四步：把mini_developerkit*.rar里面的：extend_rootfs/perf拷贝到squashfs-root/usr/bin中（或者任何二进制目录中都行）；scripts/minirc_boot.sh拷贝到squashfs-root/var目录中。
第五步：修改一下squashfs-root/etc/rc.local，进入/var后调用/var/中的minirc_boot.sh（插入内核模块完全靠这个脚本完成的。进入某个目录然后调用一个脚本这也是一个不好的设计实践，制造了多余的依赖，但我懒得改了）。这个minirc_boot.sh第一次启动的时候会安装和设置对应的驱动目录，如果你担心失败，我推荐你用chroot自己调试一次，但它除了安装，又启动了一堆daemon，所以不要指望太顺利，所以最好就一次成功不用调试吧。
第六步：给你的系统增加一个叫HwHiAiUser的用户，因为这个minirc_boot.sh依赖这个（我实在很难理解这是什么脑子做的设计，而且，估计设计者从来没有正经增加过这个用户，因为如果他正经用useradd增加这个用户，就会知道Ubuntu把这个名字定义为：“bad user name”）
这样得到的squashfs-root才是可以正常启动到可以进入网络和ssh的。
这样把SD卡插进去，连上电源和网络，开始自求多福吧。因为只要系统不能启动到网络正常，sshd启动正常，你面对的就是一块砖。一般来说，你盯着那个网口的灯就可以猜：加电的时候是两个灯都亮的，如果网口正常初始化，他们都会灭掉，如果不能灭掉，说明网口肯定没有起来，那就是块砖了。
在我这里，两台设备的网络都极易闪断，由于我的工作系统是Ubuntu，闪断后地址就丢失，每次都要重新配置，建议连上以后，用USB连你的工作PC，网络连到你的局域网上，用dhcpc来工作，这样可靠一些。（注：我的经验是，用上半小时就稳定了，这应该是个硬件问题。但一个4000块的产品，硬件做成这样，实在说不过去。）
而且，这块单板居然没有关机后的timekeeping，每次重启时间都需要重新设，WTF。
最后说句好话：这是一个8核ARM系统，速度接近PC，用来做ARM本地编译还是不错的（当然，这属于买椟还珠了）——编译一个defconfig的Linux Kernel用时50分钟——当然，如果真编译Linux Kernel我是不太可能用的，小程序还马虎吧。
（todo：晚点我补充一下在HostUI上编译的达芬奇程序如何在Atlas的Linux中运行，但这个也需要时间，因为根本就没有文档清楚说明这些程序的结构和关系是怎么样的。）
最后，让我再总结一下“守弱”这个主题吧。这个Altas的官方文档（当然他们说会去改，以后可能会好很多，我现在讨论的是2019-9-30我看到的版本），丢开工程师Linux发行版开发经验不足这问题不说，整个设计风格表现出来的是一种“守强”的写作（设计）风格。“守强”的风格类似“三个锦囊”。老评书总喜欢玩这个梗：一个人要出去办事，神机妙算的军师给他三个锦囊，告诉他：遇到困难的时候打开，按着做就能逢凶化吉。在现实中能这么弄的军师，我觉得至少得是个上帝级别的职称吧——你面对一个复杂的情形，可以用一个死板的模式就解决问题？这是不面对现实，自以为自己是上帝。所以我把这称为一种“守强”——明明做不到，事实不是如此，却非要去充大头鬼。
上面的文档充斥着这种写作风格：你先这样，在那样，再那样……这样就可以的，其实根本不可能可以，除非你不在乎你自己机器的配置，同时拥有一台和设计者完全一样的机器。实际上我对比了一下，由于Ubuntu升级，我自己做的Ubuntu版本的内容已经和设计者后来发给我的SD卡的目录结构不完全一样了。
另一方面，设计者根本不在乎Ubuntu原来的设计逻辑，比如加一个Service应该加到systemd的控制中，每个用户只控制自己的目录等等，把对方的系统当做自己家了，想怎么加就怎么加，加完难道人家的系统就用你一个功能吗？这种写法，设计者和使用者直接没有任何确切的依赖可言，所有细节都得完全一致，这以后怎么升级和改进？这样做的产品，其实就不叫一个产品，它就是一个“服务”，你要跑，我用一个标准的Ubuntu改造到你能用，以后再要干什么，我要用一个新的ubuntu，再给你做一个，架构是Ubuntu的，我自己，就是一次次给你“服务”而已。“三个锦囊”这种设计，说出来好牛逼，但只能写在小说中，真这样干的时候，不开锦囊你觉得它牛逼，真打开了想用你只想骂娘。
换成守弱的写法，退到可靠的依赖上：我直接告诉你我提供了什么，我怎么考虑我的东西可以被运行到你的系统上的，我让你创建一个用户，是为了什么。我给你做一张SD卡，我的这个卡的要求是什么，用户遇到问题了，就能自己解决，也就是能够帮你，这种情况下，你不怎么牛，但这解决问题。这就是守弱。很多时候，（在做法上）承认自己的无能，承认自己只能解决一点点问题，反而最终能解决那个大问题，强顶着，非要说自己能解决问题，说些大而无当的话，想帮你也没法帮啊。这是和天作对，这免不了就“失道”了。
再强调一下，我们说“守弱”，这是个“道”，不是个名。不是说你就不能给出固定的方法让用户实施，也不是让你写文档总写成让用户“具体问题具体分析”的样子。“具体问题具体分析”不是用户喜欢的，谁用一个产品不希望用一个简单的逻辑都可以搞定呢？关键在于你行不行。你这个地方没有Pattern，不能一下搞定，你才需要从基础逻辑开始建模，把你的内里和逻辑暴露给用户，动用用户的头脑。在设计上，我们确实希望用户简单，比如我们前面提到的，你在HostUI上对Ubunut有很多依赖，说都说不清楚，你直接给一个Docker Image，这一点问题没有，里面的复杂度你留给自己，用户只关心用特定的用户权限启动一个Docker Instance，这一点问题没有，你以后升级都只升级整个Docker Image，这也很好（但你需要承担维护成本上的困难，但这是个权衡而已）。但你不能明明很复杂，说些好像很“决断”的话，不实施以为你成竹在胸，一实施就知道你胡说八道，领导质疑你来个“不是我的错，我说的每句在我这里都是可以的”，这种“我没错”的设计思路，永远都做不出好的产品来。
补充：最后再补充一下对这块板本身设计的成败总结：
- 用USB直连PC的想法不错，这样调试起来很方便，比NV的方案连显示器实用多了，但为什么不干脆把这个同时做一个串口？这样爱怎么弄都行了。
- 软件直装Ubuntu的想法不错，但麻烦好好遵循一个正常的Ubuntu的方法来维护它，不要变成一团乱麻。产品环境不是试试就完事的好吧，这玩意儿有个维护周期在里面的。Boot相关的固件也不应该放在root中，放在一个独立的分区中好好的，用特殊的flag一类的标记区分，相关启动参数都可以放在那个分区中，这才是标准的可以持续维护的做法。
- 不支持Wifi，网络不稳定，差评。
- HostUI和Atlas的安装请相互独立，不要合并成一团乱麻好吧？
- 软件方案一团糟，但还是可以救的，好好设计一下吧。
- 用户手册也一团糟，这和软件方案一团糟是互相帮助的，怎么弄，开发团队自己知道。这个地方关键是名称空间的定义，你推这块板是为了让别人用你云上的方案，你哪里和云上是一致的，哪里不是，根本就分不清楚（大概率是一大群人互相就没有弄请求，每个人都说些冠冕堂皇的话，最后就是谁都不知道哪里是承诺，哪里是“恰巧”，这样的系统自然就是没有架构的。但正如前面说，你不做架构，架构就来“做”你。一个东西只要使用，就会产生不能动的部分，这些部分处于无关紧要的位置上，这个东西就什么都改不了，然后就死在那里了）
- AI功能还没用，等用起来再回来评价吧。
1555
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
