asset:所有图像资源均切换到OSS图床。

source/_drafts/about-systemctl.md

@@ -0,0 +1,11 @@
+---
+title: systemctl命令的使用
+tags:
+  - Linux
+  - Service
+  - 命令
+  - systemctl
+categories:
+  - - DevOps
+    - 系统管理
+---

source/_drafts/travel-note-21-04-30.md

@@ -0,0 +1,14 @@
+---
+title: 游记 - 2021.04.30 - 目的地：张家口
+tags:
+  - 游记
+  - 张家口
+  - 自驾游
+categories:
+  - - IT以外
+    - 游记
+date: 2021.04.30 22:05
+---
+又逢五一假期，这次计划去看看传闻已久的草原天路。
+{% oss_image 化稍营服务区.jpg CAEQDxiBgMCC.q7XyRciIGI4ZDljZTkyNGMzNDRiYmQ4OGJmZTAyMzc4NmM4NTMx 化稍营服务区看雪山 %}
+{% oss_video 张家口-风雪高速路.mp4 CAEQDxiBgICypszZyRciIDQ3YjczYzZhZmMxMDQwN2U4NzRlMTQ1ODg0ZDlkNzIx %}

source/_drafts/travel-note-21-05-01.md

@@ -0,0 +1,17 @@
+---
+title: 游记 - 2021.05.01 - 意外之旅：沽源
+tags:
+  - 游记
+  - 自驾游
+  - 张家口
+  - 沽源
+  - 闪电河
+  - 闪电湖
+  - 天鹅湖
+  - 桦皮岭
+  - 草原天路
+categories:
+  - - IT以外
+    - 游记
+date: 2021.05.01 22:05
+---

source/_drafts/travel-note-21-05-02.md

@@ -0,0 +1,13 @@
+---
+title: 游记 - 2021.05.02 - 文化一日游：怀来
+tags:
+  - 游记
+  - 张家口
+  - 怀来
+  - 鸡鸣驿
+  - 黄帝城
+categories:
+  - - IT以外
+    - 游记
+date: 2021.05.02 22:05
+---

source/_drafts/travel-note-21-05-03.md

@@ -0,0 +1,14 @@
+---
+title: 游记 - 2021.05.03 - 壮美太行：蔚县
+tags:
+  - 游记
+  - 张家口
+  - 蔚县
+  - 涞源
+  - 飞狐峪
+  - 空中草原
+categories:
+  - - IT以外
+    - 游记
+date: 2021.05.03 22:05
+---

source/_drafts/ubuntu-tips.md

@@ -0,0 +1,38 @@
+---
+title: Ubuntu Server技巧合集
+tags:
+  - Ubuntu
+  - Linux
+  - 操作技巧
+  - 常用命令
+categories:
+  - - DevOps
+    - 系统管理
+date: 2021.04.28 10:28
+update: 2021.05.03 22:57
+---
+## 安装X Server
+
+## 让Ubuntu Server启动到命令行
+
+在为Ubuntu Server安装了X server以后，再次启动Ubuntu Server会自动进入到等待登录的图形界面上，如果不需要这个界面，可以使用以下命令来使Ubuntu启动到命令行界面。
+
+```bash
+sudo systemctl set-default multi-user.target
+```
+
+执行完这个命令以后不要忘记使用`sudo reboot`重启机器以使配置生效，并检验命令效果。
+
+## 阻止Ubuntu进入休眠
+
+想要阻止Ubuntu进入休眠状态，可以将用于控制休眠的服务屏蔽掉，于是可以使用以下命令。
+
+```bash
+sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
+```
+
+当这条命令执行成功以后，可以使用以下命令来查看当前系统的休眠状态。
+
+```bash
+systemctl status sleep.target
+```

source/_posts/avl-tree.md

@@ -56,7 +56,7 @@ public class AVLNode extends BSTNode {
 
 向一个AVL中插入或者删除一个节点，会导致AVL的不平衡。例如以下示例。
 
-{% asset_img avl-insert.svg 'AVL树插入节点导致不平衡' 400 %}
+{% oss_image avl-tree/avl-insert.svg CAEQDxiBgICq0NndyRciIGM1ODczMDQ3MmQ2YzQ1MDY5YTk0MmUxZjVkYzI0YTgw 'AVL树插入节点导致不平衡' 400 %}
 
 左侧的AVL在插入一个新的节点5之后，就变得不平衡了。节点50的左子树的高度为4，右子树的高度为2，AVL已经失去了平衡。在这种失衡的情况下，AVL是通过旋转最小失衡子树来重新获取平衡的。那么这里就引入了一个新的名词：**最小失衡子树**。
 

source/_posts/binary-search-tree.md

@@ -17,7 +17,7 @@ mathjax: true
 
 以下是一个BST的示例。
 
-{% asset_img bst.svg 300 %}
+{% oss_image binary-search-tree/bst.svg CAEQDxiBgICb0NndyRciIGIzYmUyZTdmYTlmYTRkZjc5MmFiNWIxODk1NWVjOTQx '二叉查找树' 300 %}
 
 可能看着这个二叉树比较丑陋，但是这的确是一个现实中常常会碰到的BST。有二叉树排序经验的读者可能会觉得这个二叉树十分熟悉，的确，BST也常常用来做排序，这和你所看到和用到的二叉树排序几乎是一样的。
 

source/_posts/binary-tree-basic.md

@@ -56,7 +56,7 @@ categories:
 
 完全二叉树可以存放在一维数组中，堆排序所使用的数据结构也是完全二叉树。以下分别是完全二叉树和满二叉树、平衡二叉树的示意。
 
-{% asset_img binary-tree-kind.png 600 二叉树类型 %}
+{% oss_image binary-tree-basic/binary-tree-kind.png CAEQDxiBgICW0NndyRciIDk4MzlhMWFmMmZlZjRmYTZhZWZmNmJmZWJlYTZhNzYx 二叉树类型 600 %}
 
 ## 二叉树的构建
 

source/_posts/docker-image-build.md

@@ -11,7 +11,7 @@ Dockerfile一般放置在项目的根目录中，文件名就命名为`Dockerfil
 
 Docker镜像是采用的是分层文件系统，文件系统的任何改动都发生在最顶层，其下的各层都是只读的。以下是一个Docker镜像的分层文件系统的示意。
 
-{% asset_img docker_layerfs.png Docker Layered Filesystem %}
+{% oss_image docker-image-build/docker_layerfs.png CAEQDxiBgMCW0NndyRciIDgxOWNhOWRmMDZlZjQ1ZTU4N2UzNWEzNDM0Y2I2MGQ5 'Docker Layered Filesystem' %}
 
 所以对于镜像的构建，实际上就是在形成要部署的应用所需的运行环境，而这个运行环境就是像上图一样，一层一层叠加起来的。
 

source/_posts/kotlin-unresolve-reference.md

@@ -23,43 +23,43 @@ Kotlin是一门JVM语言，可以自由的调用Java中的所有库功能，这
 
 先来看一个编译示例。
 
-{% asset_img error-prompt.png 350 编译示例 %}
+{% oss_image kotlin-unresolve-reference/error-prompt.png CAEQDxiBgIDvldfdyRciIDZiZGVmMDIzMjZhODQwZDRhOTViMGRjNzg3ZDc1ODcz 编译示例 450 %}
 
 一个项目在使用`./gradlew run`构建运行的时候报出了`Unresovled reference: readString`错误。这个`readString`是调用的`java.nio.file.Files.readString()`方法。可是为什么会报这个方法没有找到呢？先来看一下这个方法的文档信息。
 
-{% asset_img file-docs.png 450 文档信息 %}
+{% oss_image kotlin-unresolve-reference/file-docs.png CAEQDxiBgMDMlNfdyRciIGZlM2M5OTY3NTQ0NzRhZTNiMmY2N2FmNGVhYjcyYTdk 文档信息 450 %}
 
 好吧，有点儿长，但是似乎看不出什么端倪来。这里要注意了，这个方法是在Java 11引入的，那我们来看看项目的构建配置。
 
-{% asset_img gradle-file.png 300 Gradle构建配置 %}
+{% oss_image kotlin-unresolve-reference/gradle-file.png CAEQDxiBgMDSk9fdyRciIGIyMGExYWE5YWVmYzRiZjVhYzM2ZGVlMTI1OTI0ZjIw Gradle构建配置 300 %}
 
 Kotlin的编译目标看起来也没有什么问题，同样是面向Java 11编译的，理论上使用这个新引入的方法完全没有问题。那么，再来看看IDE中的项目配置。
 
-{% asset_img ide-setting.png 450 IDE项目配置 %}
+{% oss_image kotlin-unresolve-reference/ide-setting.png CAEQDxiBgMDXk9fdyRciIDkyZGMwODRmYjJiMjQyYjBhMTZhZDQyZGI2Mzc4ZWY5 IDE项目配置 450 %}
 
 好，项目配置这里依旧没有问题。那么Gradle构建Kotlin项目所所涉及到的两个JDK版本问题就已经确认了一个了。那么我们来看另一个JDK配置。
 
-{% asset_img system-setting.png 450 系统JDK %}
+{% oss_image kotlin-unresolve-reference/system-setting.png CAEQDxiBgMCLlNfdyRciIDQxYzZmMTA1MGU5NTQzMzI5YmNlN2Q3ZmNhODkwOTc0 系统JDK 450 %}
 
 呃，好吧，我机器上的Java是通过SDKMan安装的，这里安利一下，真的很好用，Windows用户就暂时不要想了。不过`JAVA_HOME`也是Java 11，这就尴尬了好不。不过不用急，能够影响Gradle所使用的JVM的还有一处位置，那就是用户家目录下的`.gradle`目录，这是Gradle保存全局配置的目录，这个目录里有一个用于配置Gradle的`gradle.properties`文件。
 
-{% asset_img gradle-setting.png 500 Gradle JDK %}
+{% oss_image kotlin-unresolve-reference/gradle-setting.png CAEQDxiBgICBltfdyRciIGNkYWQwMWRjMWQ3NjQ3ZjJiNDQ3YjY5M2ZiNDZkY2I0 'Gradle JDK' 500 %}
 
 看起来我们似乎找到了问题的源头，Gradle没有在使用环境变量中配置的`JAVA_HOME`，而是使用了`.gradle/grade.properties`中另行指定的JDK目录。那么修改它一下试试。
 
-{% asset_img gradle-setting-modified.png 500 Gradle JDK 修改后 %}
+{% oss_image kotlin-unresolve-reference/gradle-setting-modified.png CAEQDxiBgMCHlNfdyRciIDI4OGIxYjZjYjIxODQxZjU5MWMxNzllNjlkOTlmODhh 'Gradle JDK 修改后' 500 %}
 
 现在我们再来试一下吧。
 
-{% asset_img second-test-run.png 350 第二次实验运行 %}
+{% oss_image kotlin-unresolve-reference/second-test-run.png CAEQDxiBgID7ldfdyRciIGEzYmUwNjk5MmJiYzQ3NjM5MzhlZmMyOTgxYmE4MzA4 第二次实验运行 350 %}
 
 呃，看起来依旧好尴尬，问题依旧。那么能够配置Gradle所使用的JVM的位置还有没有呢？这个位置还真的还有一个，那就是IDE中的配置。
 
-{% asset_img ide-gradle-setting.png 450 修改IDE中的Gradle配置 %}
+{% oss_image kotlin-unresolve-reference/ide-gradle-setting.png CAEQDxiBgMDXk9fdyRciIDkyZGMwODRmYjJiMjQyYjBhMTZhZDQyZGI2Mzc4ZWY5 修改IDE中的Gradle配置 450 %}
 
 IDE中配置Gradle使用的是Java 8，那么把这里也修改成Java 11试试看。
 
-{% asset_img third-test-run.png 350 成功运行 %}
+{% oss_image kotlin-unresolve-reference/third-test-run.png CAEQDxiBgIDLk9fdyRciIGQyMDJiZDNkY2RmYjRlNDFiZjFiOGQzOWMyOTYzYjJi 成功运行 350 %}
 
 至此，由于Gradle所使用的JVM配置错误而导致Kotlin发生“Unresolved reference”的问题已经全部解决。这个问题是由于Gradle使用的JVM是Java 8，其中并不带有项目中所使用的Java 11的内容，而Gradle所使用的JVM又是项目编译所要使用的JVM，这就导致了Kotlin报出“Unresolved reference”错误。