伴随着我服务器的切换，最近把Nextcloud云盘从服务器上头下线了。它确实很强大，但强大的同时也意味着臃肿。而我只需要这臃肿中的同步功能。而它的同步又是全量同步，且不好设置需要同步的文件夹，这就偏离了我自己的需要了。所以一句话，我只需要一个可以增量同步我指定的任意文件夹下的内容的工具。

曾经使用过坚果云。但是每月1G上载3G下载的流量限制让我最终放弃了它。

Dropbox，印象里很不错。但是用它还得翻墙，不值当的。

OneDrive，微软家的东西，很好用。但是速度实在是不稳定。

最终，还是在服务器上面搭建了一个同步工具——Syncthing。

这是一个开源工具，据说类似于BTSync的开源实现（这个我并没有考证）。正好符合我的需求：简单、增量同步。不过说是“同步盘”，其实更像是两个朋友间“共享文件夹”。因为这个工具，无论是服务器上还是终端上，安装的都是相同的程序，只需事先添加对方到列表，即可开始文件夹的“共享”之旅。下面具体说说怎么搞。

不必纠结下面的步骤哪个是服务器的哪个是客户机的。因为步骤都一样。

一、服务器 & CentOS

我更倾向于用Docker安装。因为手工部署需要人工把服务文件复制到systemd中，如果更新的话还需要再操作一遍。对于服务器，使用其他方式安装还需要额外配置，就麻烦了。Docker方法如下：

1. 拉取镜像。关于这个工具的镜像有很多，其中我更倾向于使用 linuxserver/syncthing。官方的有权限问题，可能是我的操作有误吧…docker pull linuxserver/syncthing

2. 建立容器。使用命令

   docker create \
     --name=syncthing \    # 容器名称
     -e PUID=1000 \        # UserID
     -e PGID=1000 \        # GroupID
     -e TZ=Asia/Shanghai \    # 时区
     -e UMASK_SET=022 \    # 文件夹权限
     -p 8384:8384 \        # 对外端口映射 - GUI端口
     -p 22000:22000 \        # 对外端口映射 - 协议端口
     -p 21027:21027/udp \    # 对外端口映射 - 本地发现端口
     -v /path/to/appdata/config:/config \    #文件夹映射 - 程序文件
     -v /path/to/data1:/data1 \    # 文件夹映射（自定义数据文件夹）
     -v /path/to/data2:/data2 \    # 文件夹映射（自定义数据文件夹）
     --restart unless-stopped \    # 始终重启容器
     linuxserver/syncthing

   其中，参数name、TZ、-p、-v都可以根据自己的情况进行修改。对于这几个端口，保证本机相应的端口没有被占用且没有被防火墙限制即可。

3. 启动容器docker start syncthing

   现在，你就可以打开ip:8384映射出来的端口号在图形化界面中设置了。其中，ip地址需要使用:

   • 本机，使用地址127.0.0.1
   • 服务器，使用地址服务器公网ip

二、Debian&Arch安装

源中已提供，直接安装对应的包即可。其中，服务器端和客户端都可使用包syncthing，客户端亦可以使用syncthing-gtk获取一个显示在托盘的同步状态标志及便捷的设置入口和服务起停入口。

• Debian系

  apt install syncthing    # 安装
  systemctl enable syncthing    # 设置服务开机启动
  systemctl start syncthing    # 启动服务
  # 如果是客户机，可使用下面的命令代替上面的
  apt install syncthing-gtk

• Arch系

  pacman -S syncthing    # 安装
  systemctl enable syncthing@你的用户名    # 设置服务开机启动
  systemctl start syncthing@你的用户名    # 启动服务
  # 如果是客户机，可使用下面的命令代替上面的
  pacman -S syncthing-gtk

对于本地机器，如果安装的包syncthing，则可打开127.0.0.1:8384进入图形化的设置界面；如果是syncthing-gtk，则找到程序syncthing-gtk，运行即可。

对于服务器，再进行下述操作：

1. systemctl stop syncthing停止服务
2. 找到syncthing文件夹，编辑config.xml，将<address>127.0.0.1:8384</address>修改为<address>0.0.0.0:8384</address>

三、GUI设置

1、服务器端

操作 - 设置，打开设置界面。

• 常规：

  • 如果不是用Docker 安装的，那么请确保默认文件路径的合理性

• 用户图形界面

  • 设置一个 图形管理界面用户名
  • 设置一个 图形管理界面密码

• 连接

  • 保证勾选了启用NAT遍历
  • 保证勾选了全球发现

2、客户端

安装的syncthing，则点击操作 - 设置，打开设置界面。

• 常规：

  • 如果不是用Docker 安装的，那么请确保默认文件路径的合理性

安装的syncthing-gtk，则打开窗口后点击右上齿轮 - 守护程序设置，打开设置界面。

• 取消其中的全部勾选

四、开启同步之旅

1. 服务器端的设置界面，点击操作 - 显示ID，复制弹出窗口中的字符串
2. 本机中，选择添加设备，ID粘贴刚复制的字符串，地址填入服务器ip:22000(或者docker容器，22000映射的端口号)，确定
3. 等一会儿，服务器会弹出添加请求，通过
4. 本机添加共享文件夹。在共享给设备中，勾选刚添加的服务器，确定
5. 等一会儿，服务器会弹出建立共享文件夹请求，通过
6. 共享已联通。同步正式开始了

在新的笔记本上头安装好Arch后，最近几次突然出现了个奇怪的问题：

系统检查完成后，sddm总是起不来。但系统是已经启动成功的，因为我可以切换到tty界面进行操作。但尝试在tty界面输入sddm，却给我返回错误：

Failed to read display number from pipe

但是，通过systemctl restart sddm重启一次服务，却又可以正常启动了，直到下一次重新启动需要再进行一次这个步骤。

真是头一次遇到这种问题……

后来在Archlinuxcn的群组里搜索了一番，看到了一个解释，说是熵不够。可以通过命令

cat /proc/sys/kernel/random/entropy_avail

来查看熵值。想要sddm启动需要差不多2000的样子。

我照做了。然后得到了刚启动时候的熵值：20

虽然到了也没明白为什么sddm启动要检查熵，但是这很明显差得太多了，那问题应该就是这里了。

有没有什么办法能提高熵的值呢？还真有。

pacman -S rng-tools
systemctl enable rngd

重启。

真好，刚启动就2700多了呢。

但是，对sddm启动的解决卵用也没有…

后来又看到一个，大概意思就是：

kabylake架构的CPU，要把驱动加入内核

来试一下：

1. 安装intel驱动：pacman -S xf86-video-intel
2. 编辑/etc/mkinitcpio.conf，在MODULES=的括号内增加intel_agp i915
3. 重新生成initramfs。以防万一，先不做覆盖：mkinitcpio -c /etc/mkinitcpio.conf -g /boot/linux-i915.img
4. 重新启动。在grub处按 e 编辑启动项，将 initramfs-linux.img 位置更改为 linux-i915.img，按F10启动

啊…终于成功了。虽然熵才30多，但sddm也终于能一次起来了。

既然启动成功了，就可以把这个自定义的名称更改成initramfs-linux.img并覆盖原先的镜像了。不过为了安全，把原先镜像做个备份大概也是有必要的。

不过，虽然解决这个问题了，但我到底也没闹清楚为什么这种架构的CPU要启用KMS，更不明白为啥提高熵也能解决一部分sddm卡住的问题…

不过还行，从解决到现在，驱动啥的都滚了几个版本了，找时间去掉这俩模块再试一下

视频点此

我曾经说，不能跟着Archwiki的Installation Guide安装好Archlinux的话，那么暂时也不要考虑用Arch了。但是最近Arch把base包组替换了之后，官方的安装文档便显的太过简略了一些…以至于我在引导问题上头卡了小半个钟头…所以，是时候分享一下base组被替换后，Wiki没有提到的内容了

注意：无论如何，官方写过的内容我还是不会去详细说的。因为只要官方文档提到了，那么它的内容就是详细且清晰的。如果看不懂，那么还是请暂时回避Arch，尝试一下Manjaro什么的。

一、替换了啥？对我有什么影响吗？

官方是这么说的：

The base group has been replaced by a metapackage of the same name. We advise users to install this package (pacman -Syu base), as it is effectively mandatory from now on.

Users requesting support are expected to be running a system with the base package.

Addendum:
Be aware that base as it stands does not currently contain:
- A kernel
- An editor
... and other software that you might expect. You will have to install these separately on new installations.

简单来说：以前只要装好base包组，你就可以拥有一个完善的文本样式的系统了。而现在，base只供满足依赖关系而不再提供可启动的软件包。所以现在的base只是一个脚手架，想要成功运行Arch就需要你自己来填充内容了。

所以，安装上面有哪些变化？

二、实操有啥变化？

从进入安装盘一直到pacstrap之前，都是没有变化的。但在pacstrap这里需要注意。

在 Installation Guide 的示例语句中，只增加了一个linux内核的程序包。但是实际上，你需要增加的可能不止这个：

• visudo依赖vi或者vim，所以需要加入这两个软件包之一。推荐vi——如果你没有在图形界面使用vi的习惯的话
• 好用的nano编辑器工具现在默认不再提供。需要的话也请再追加这个包
• dhcpcd同样需要自己安装。可以在这里追加，或者之后的arch-chroot时候使用pacman安装

然后，一切如常。直到进行到grub安装环节。

不知道是不是只是我赶上了一版“残缺”的内核…不过为了保险，还是推荐这么操作一下，省的到时候进入grub恢复环境。

• 一如既往地，安装grub和efibootmgr软件包并使用grub-install和grub-mkconfig写入一次引导
• 使用pacman -S linux重新安装一次内核
• 同样的，使用pacman命令重新安装一次微码
• 使用grub-mkconfig重新写入一次引导

不出意外，改版后的Archlinux就可以成功启动了。

所以，改变的说大也不大，仅仅是需要额外补充一些软件包；但是说小也不小，想让grub顺利引导还是有点儿东西的。不过还是前边说的那句话，可能只是我当时赶上了一个残缺的引导部署版本，可能到你安装的时候，只需要额为补充一些软件包就可以了。

最近到手了一个很轻便的笔记本，换装Arch的时候遇到一个问题：界面会不断地刷pcie bus error的提示,类似于

pcieport 0000:00:01.1: PCIe Bus Error: severity=Corrected, type=Physical layer, id=00e5(Recelver ID)
......

不断刷屏，根本不知道自己的命令打成了什么样，更不要提查看结果了。

几经查阅，发现这个问题大概是由于硬件间通信速度不同导致的错误，除了更换插槽以增加两个硬件之间的物理距离外，没有其他的解决方案。所以如果系统运行正常，那么搁置这个问题即可。

所以，解决无望，只能想办法屏蔽这条消息。

方法很简单。在Arch安装盘的选择界面按e（类似于编辑grub的启动项），结尾增加 pci=nomsi，再回车进入安装程序即可。

同样的，如果在安装之后还出现这个问题，则可以将这个参数加入grub启动项中来解决。不过我这里在装好之后就好了，所以我感觉这可能是USB插槽距离CPU或者某些控制器有点儿近导致的吧…

根据Archlinux官网公告，原本的 base 包组（group）已经被替换为同名的元包（metapackage）。所以安装Archlinux过程需要至少额外补充内核的安装项。

installation guide相关内容已更新，安装请参考。

这个文章有点儿啰嗦…要看解决方案到底是什么的，就直接拉到文章最后一节

笔记本，Intel核显+NVIDIA独显，解决方案？

只安装NVIDIA独显闭源驱动？大黄蜂切换？nouveau？

正确的方式是什么？

一、为什么放弃了大黄蜂

本身我一直推荐用户通过大黄蜂+bbswitch来实现双显卡切换。但直到前些日子我打算玩儿{{theHunter：Call of the Wild:猎人：野性的呼唤}}，它不能运行了。

我知道这个游戏是Windows专属，所以它是通过Proton来实现运作的。但是根据protondb.com给出的数据，这个游戏的支持度是很好的。

怪哉！

实在没有办法，只好用steam play bumblebee为关键词搜索，偶然看到了个描述（原网页懒得找了）：大黄蜂不支持dxvk

原来问题在这里。

那就不得不放弃大黄蜂了。

二、选啥方案

只安装闭源驱动？

性能是好，但是太费电啊…

nouveau？

省电，还能自动切换，但独显性能太渣了啊…况且好像还不能执行CUDA？

Ubuntu有着Linux世界里边最好的I+N双显卡解决方案，叫做PRIME。这个方案是通过在显卡管理器中更改配置文件达到使用核显或独显的目的的。Arch有没有类似的？

三、找到了可能是最好的方案

ArchWiki一查，还真有：nvidia-xrun

很明显，这个方案比Ubuntu的PRIME方案复杂了太多太多。而且使用时还需要切换到一个字符界面。但它确实能提供完整的英伟达显卡性能，在不使用的时候也可以关闭。

顺着这篇wiki,我又来到了Graphics索引页面。然后看到了一个名字为NVIDIA Optimus的Wiki项。要知道，Arch下面的显卡方案往往都被归类为Optimus。所以点进这个Wiki看一看。

emmm... nouveau, Bumblebee, nvidia-xrun。没什么特别的。

难道就只有这种通过tty载入独显驱动一条路了吗？

不！任何时候都请记住：养成查看英文页面的好习惯。

看到变化了吗？看到英文页面的5.4小节了吗？就是它！只需从托盘右键选择一个显卡，就可以自动注销并切换！比Ubuntu需要打开显卡管理器—选择配置文件—手动注销再登录还要简便！而且还不需要xrun那样事先配置一堆文件！简直是赶超Ubuntu驱动管理的最佳选择！

四、配它

简单到什么程度？只需装几个软件包，再点几下鼠标即可完成：

pacman -S nvidia bbswitch    
# nvidia: 英伟达闭源驱动。如果使用自定义内核，或者不想驱动崩掉，那就安装nvidia-dkms
# bbswitch: 切换使用的节能工具。如果使用自定义内核，那就安装bbswitch-dkms

yaourt -S optimus-manager-qt
# 托盘程序（可视化切换及设置）。会自动安装核心程序
# 如果配置有archlinuxcn源，那么同样可以使用pacman来安装
# 如果使用KDE桌面，另有optimus-manager-qt-kde可供选择

现在重启，应该就能看到托盘多出了一个小图标了。右键点击它，选择设置—Optimus，Switching method选择Bbswitch，确定保存。

完成了。以后只需要右键这个图标，选择对应的配置方案，便可进行切换了。

所以，总结一句话：

一定记得看英文页面

注：

• 根据项目readme，仅支持Arch分支的发行版
• manjaro由于自带电源管理和自己的大黄蜂驱动方案（一样的残缺），需要对照git项目，删除/修改指定的配置文件以完成部署

对应的git项目 点这里

如果发现默认设置还是不能启动proton游戏，尝试如图配置