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

笔记本，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游戏，尝试如图配置

随着我的学生机越来越接近终结时刻，在上面运行的服务不得不要陆续的转移到现如今的服务器上面了。

我的RSS服务就是一个。

但是，现在这个服务器是OVZ的，内核只有可怜的2.x。而Docker要求的最低内核是3.14，所以这个TTRSS要转成普通安装方式来进行。

但毕竟之前一直用Docker，这冷不丁的通过手工部署还真有点儿费劲。所以还是记录一下。

一、新建站点

宝塔中，新建一个站点：

1. 域名、备注、根目录都随意。比如我使用域名rss.nonickname.garss.bwsl.wang。这样便可以直接访问这个网址来使用RSS服务（当然，域名解析要配置好）
2. FTP可以不要
3. 数据库：MySQL
4. PHP选择7以上的版本
5. 提交

二、部署站点

1. ssh到服务器（ttrss的包下载zip会失败，只能用git clone。不知道为什么），输入以下命令克隆文件

cd /path/to/ttrss #进入ttrss网站的根目录
git clone https://git.tt-rss.org/fox/tt-rss.git #克隆文件

2. 克隆完毕后，可能会多一层文件夹(也就是说，可能/path/to/ttrss/tt-rss/下才有index等等的文件)。将里边的所有文件剪切到网站根目录(/path/to/ttrss)
3. 因为git到的文件拥有者是ssh登录用户，而不是网页处理的用户。所以退回到上一层(/path/to)，修改拥有者为www(记住勾选应用到子目录)

三、安装站点

配置好解析之后，输入网址以启动安装程序。根据要求输入即可。

如果权限正确，这时候应该就可以直接通过默认用户名和密码进行登陆了(admin/password)。一定记得在第一时间修改密码。

四、配置站点

编辑网站根目录的config.php：

• FORCE_ARTICLE_PURGE修改成大于0的数，以自动清理超过这个数字天的文章（星标除外）
• ENABLE_GZIP_OUTPUT选开。开启可以获得更好的加载速度，但是需要安装php的zlib扩展

保存

五、配置更新feed

不进行这一步是不能刷新Feed的。

1、使用简单模式

编辑config.php，将SIMPLE_UPDATE_MODE改为true，保存。

这种更新方式是指，每当用户使用网页登录ttrss时才进行刷新。通过应用登录无法获得新内容。

2、通过定时任务

进入宝塔的计划任务，新增shell脚本。内容为：

sudo -u www php /path/to/ttrss/update.php --feeds --quiet

设定好执行间隔，保存即可。

至此，TTRSS的手工部署过程便完成了。

更多内容，去往ttrss官方查找

六、配置获取全文

虽然限制Feed只能获取部分，一定程度上可以保证提供Feed服务的同时不降低网站流量，但是只能获取部分内容确实让Feed的体验有些差。所以，很多 RSS 服务或客户端将全文获取作为 Premium 订阅的卖点之一。不过，通过 Tiny Tiny RSS，我们同样可以免费实现这一效果。

之前在网络上看到的，都需要去其他api提供网站上先行注册，这对于我这种不喜欢注册账号的人很不舒服。不过，最近发现了一个插件，直接解析网站结构来实现抓取全文，使用起来还是不错的。下面简单介绍。

插件名称：af_feedmod

使用方法：

1. git clone 上述项目到 ttrss 根目录(会自动放入插件文件夹)
2. ttrss的偏好设置 - 插件中，启用af_feedmod
3. 保存后，设置页面多出一个FeedMod标签页，打开

4. 仿照下述格式输入

   {
   
   "jpmetro.com": {
    "type": "xpath",
    "xpath": "/html/body/section/div[1]/div/article"
   },
   
   "www.linuxidc.com": {
    "type": "xpath",
    "xpath": "//*[@id='content']"
   }
   
   }

手工部署这一次，更让我感受到了一个问题：傻瓜化与繁琐是互斥的，随之而来的是可控与不可控的选择。

因为之前用Docker，所以这次整个过程中，出现了相当多的问题。包括但不限于权限出错、feed不更新等等。

这是一个非常矛盾的选择。

选择了简单、一键、Docker，这在安装时固然便捷了很多，但却有了更多的不可控因素。一旦出现问题，排查过程便是一个极度困难的事情——你并不知道这个一键的背后都做了什么，安装的文件都放在了何处。即使从网上找到了很多的解决方案，但找不到文件在哪儿，本身最简单的事情却成了查错路上最陡峭的一所大山。

就像用宝塔安装的php。它的执行文件并不在默认的/usr/bin/php，而是自定义的/www/server/php/版本号/bin下面。我很庆幸我找到，并且记住了这个位置。如果在我知道这个位置之前便出现了php问题，可能解决错误的唯一方式就是重新安装php了——至少为了知道php在哪儿，我还需要花费额外的时间去论坛询问，或者查阅官方文档。

而选择手工部署，一开始可能需要大量的准备工作。但这样部署的结果，就是我明确的知道哪个文件在哪里，它都能帮助我完成什么任务。这是完全透明的一种操作体验。无论什么地方出现了哪些问题，我至少不会因为找不到文件而搁浅修复的计划。

所以还请好好想一想：当你感觉一个东西应该有一个一键安装包来简化安装的繁琐时，这种简化到底是不是真的对你有帮助？

一个小问题

最近感觉我订阅的很多源都没有更新了。但是到它们的网站上看却是正常的。后来登录到ttrss的设置界面尝试调试一下信息源，发现会统一报一个错误：60 SSL certificate problem。

经过一番搜索尝试，发现解决方法很简单：

进入ttrss的目录/includ/functions.php，在大概280行一堆curl_setopt位置加入一行新的

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

保存即可。

滑动返回APP下载链接：

app2站

博客内

视频点此

霍金说2032年是世界末日——当然怹老人家到底说没说过咱也不知道。到底是不是真的咱也不敢问。只是那一年有个小行星会跑到地球附近，碰撞概率是千分之一。概率虽高，但仍有很大的不确定性因素。所以当下的人们，更重视并着手解决着另一个世界末日——Unix世界的末日。因为它已经不可避免的会发生，并且发生时间已经明确了：格林尼治2038年1月19日3点14分7秒，北京时间11点14分7秒。这一点可以跟Siri证实一下。

为什么？

就像世纪初的千年虫，2038年是属于Unix的“千年虫”——使用 POSIX 时间的 32 位计算机应用程序在到达2038年1月19日3点14分7秒后，将会跳到1901年12月13日20点45分52秒继续。怎么会这样？

在Unix世界中，时间是通过一个秒数——从Unix创世元年（1970.1.1 0:0:0）到现在经过的秒数——记录的。所以在Unix里边看到的时间，都是通过创世纪时间+秒数得到的。而这个秒数，被保存在了一个32位有符号整形中，通过正负号表示0时刻之前和之后。

如果你学过编程，你应该就知道32位有符号整形是什么意思：32位的二进制数，其中最高位表示正负。位数有限，则可以表示的数字便也会有极值。这个最大值取在01111111 11111111 11111111 11111111这个二进制数上，对应的十进制就是2^31-1=2147483647。这么多秒换算成时间，就是68年零18天3小时14分7秒。加上创世纪的1970年1月1日0时刻，便得到了这种记录方式的最大时间——2038年1月19日3点14分7秒。再往后，二进制的数字进位，首位变成了1。而首位为1意味着是负数而不是+1，所以时间跳回，Y2038问题便出现了。

这个问题有什么影响吗？至少使用time_t函数的C语言程序会导致时间溢出，Unix系统也不例外。但几乎可以肯定的是，不会有千年虫的影响大。因为OpenBSD直接粗暴的把变量换到64位有符号整形来保存，Linux内核虽然不能这么干，但一直在致力于解决这个问题。而截止到5.1内核版本，其已经开始引入2038年安全的系统调用了。最终目的是让老程序能转换到正确时间，新程序则直接用64位保存时间，这便可以让时间正确运行到大约2920亿年以后。也就是说，64位的“千年虫”将在2920亿年以后出现。而你的电脑硬盘则在38年后的几十年便转秃噜轴了，太阳也早在两千八百多亿年前就变成了红巨星并一点点的冷却了，所以64位的“千年虫”，我们怕是见不到了。

视频点此

著名的github，私有库要收费，国内的码云倒是可以创建，但私有库所有协作人数总计不得超过 5 人，多多少少都有一些限制。搭建自己的git版本控制工具，保证私有库真的私有的同时，还能避免可能发生的网络环境问题。加之docker的辅助，3分钟，就能构建完毕。怎么做？

1、拉取镜像

docker pull gitlab/gitlab-ce

获取gitlab镜像。gitlab就是今天的主角。

2、创建文件夹

需要将容器的文件夹映射出来，保证镜像更新时候内容不会丢失。

cd /home #随便打开一个目录，用于新建文件夹
mkdir gitlab gitlab/config gitlab/log gitlab/data 新建文件夹，一会儿映射使用

3、执行

docker run -d -p 443:443 -p 2222:22 -p 8080:80 -v /home/gitlab/config:/etc/gitlab -v /home/gitlab/log:/var/log/gitlab -v /home/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce

跟以前用到docker的应用相比，这次的参数略多。但是万变不离其宗，主要还是使用端口映射和文件夹映射的参数。其中：

• 443:443：容器ssl端口映射到服务器的443
• 2222:22：容器的ssh端口映射到服务器的2222
• 8080:80：容器的网页端口映射到服务器的8080
• /home/gitlab/config:/etc/gitlab：容器的配置文件映射到服务器的/home/gitlab/config
• /home/gitlab/log:/var/log/gitlab：容器的日志文件映射到服务器的/home/gitlab/log
• /home/gitlab/data:/var/opt/gitlab：容器的数据文件映射到服务器的/home/gitlab/data

4、放开端口

因为安装过宝塔，所以需要将使用到的端口放行。像我这里就要放行8080、2222、443

其实在宝塔的应用里边可以一键安装gitlab。但毕竟宝塔不是所有人都装的，它的安装逻辑也更不清楚，所以相对来讲，还是docker的可控性更高一些，想删除的话，docker也可以删除的更彻底。

好了，现在输入服务器ip:8080即可访问搭建好的gitlab了。第一次登录会让设置一个密码，这个密码对应的是初始管理员密码。我们就可以通过账号root来登录管理了。

这个问题应该是从72版本开始的——如果我没记错的话。但是目测不会是Chrome的bug，因为到了76版本更加的变本加厉了…不过还好，办法总比困难多。

1、版本号≤75

具体来说应该就是72~75吧。这几个版本号还是比较容易解决的。只需要去往chrome://flags，将Enable Network Service给禁用掉即可。

究其原因（下面这些都是我猜的），大概就是从72开始，Chrome将网络服务作为独立进程执行。而系统监听的是Chrome这个进程，并没有相应真正发送网络请求的进程，所以Chrome的请求便直接发出去，不能经过代理了。而将这个选项禁用，也就是让Chrome的网络服务运行在程序内，那么网络请求便可以被监听到，PAC模式便也正常了。

2、版本号76+

76应该是最新的版本号了——至少在Archlinux里面是这样的。

即使之前你已经调整过，并且顺利解决了，但当你升级到了76这个版本号的时候，就能惊喜的发现：这个问题又复发了。

如果你还想按照75-的那种操作方法修正，那么很遗憾，Enable Network Service这个选项已经不存在了。

所以可以证明一件事：72~75出现的问题不能说是Chrome的bug，而是Network Service这个新特性导致的问题，而且Chrome大概是不打算修复这个问题的…

但总不能一直使用全局系统代理吧…国内网站绕一圈国外再回来…太慢了。

所以还是要想想解决方案，让PAC模式可以应用。

如果在Chrome://flags里边，以Network Serivce为关键字查找的话，会找到一项Runs network service in-process的选项。回顾一下刚刚说到的出现这个问题的原因，仿佛这个选项会管用？

很不幸，这个选项是没用的。所以暂时就不要想着能通过Chrome自己的设置来解决这个问题了。

好在Chrome的插件里边有一个神器——SwitchyOmega。通过它来判断是否需要使用代理就行了。

• 从Chrome应用商店安装 Proxy SwitchyOmega
• 进入插件设置页，新建情景模式（我这里名字叫做proxy），类型代理服务器
• 在这个情景模式下，设置代理协议为SOCKS5，服务器和端口为127.0.0.1:1080（这两项应该与你代理软件内对应的本地设置相同）
• 新建一个情景模式（我这里名字叫做auto switch），类型自动切换模式

• 在这个情景模式下，添加规则列表，格式为AutoProxy，网址https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt，对应这一条的情景模式选择刚刚创建的proxy。看图

  

• 点一下立即更新情景模式，待正文框内出现内容，代理便设置完成

现在，点击Chrome地址栏边上的SwitchyOmega图标，选择auto Switch，问题便解决了。

其实这样设置之后，并没有通过系统的PAC，而是Chrome自己判断并决定是直接访问还是间接访问。也就是说，即使系统没有配置好全局的PAC，而仅仅是启动了一个代理服务，通过该方法同样可以让Chrome顺利跨越。所以，为了不荒废系统代理的作用，还是希望有朝一日Chrome的Network Service可以被系统监听到并响应吧…