2019年5月

商店中的OBS版本实在不敢恭维…尤其到了15.7以后,推流总会闪退。遂想到来自己编译最新版本的OBS。而本着服务大众的理念,便将其打包成Appimage格式,便于传播的同时还可以避免各种依赖的问题。

一、编译安装OBS

OBS是开源软件,所以可以方便的从官方网站获取源码进行编译安装。

  1. 使用命令  sudo apt install build-essential pkg-config cmake git-core checkinstall 完成编译环境的搭建
  2. 使用
sudo apt install libx11-dev libgl1-mesa-dev libvlc-dev libpulse-dev libxcomposite-dev libxinerama-dev libv4l-dev libudev-dev libfreetype6-dev libfontconfig-dev qtbase5-dev libqt5x11extras5-dev libx264-dev libxcb-xinerama0-dev libxcb-shm0-dev libjack-jackd2-dev libcurl4-openssl-dev luajit-5.1-dev swig python3.6-dev libluajit-5.1-dev python3-dev ffmpeg 

安装依赖包

  1. 安装aac依赖: sudo apt-get install libavcodec-dev libavfilter-dev libavdevice-dev libfdk-aac-dev
  2. 编译安装OBS。下列命令依次执行(首先安装好git和cmake命令):
   git clone --recursive https://github.com/obsproject/obs-studio.git 
   cd obs-studio
   mkdir build && cd build
   cmake -DUNIX_STRUCTURE=1 -DCMAKE_INSTALL_PREFIX=/usr ..
   make -j4
   sudo checkinstall --pkgname=obs-studio --fstrans=no --backup=no --pkgversion="$(date +%Y%m%d)-git" --deldoc=yes

编译安装完成,同时,在 obs-studio/build 下面可以找到一个deb格式的安装包。如果没有更新需要,保留这个安装包,以后就可以直接安装了(需要安装依赖)。

二、打包成appimage格式

诚如前面所讲,现在拥有的deb还是需要各种依赖才能正常安装运行的。如果为了携带或者便于传播,可以将当前版本打包成appimage格式的包。这样,通过一个文件便能在几乎所有Debian系的Linux上面运行了(不敢说RHEL系也能用,但是至少Debian系足够了)

  1. 前往 https://github.com/AppImage/AppImages ,点击文件列表右上绿色的Clone or Download按钮,弹出气泡选择Download ZIP,获得脚本
  2. 将下载得到的ZIP文件整体解压出来,得到一个名为 AppImages-master 的文件夹
  3. 将前面编译得到的deb文件复制进这个文件夹
  4. 在这个文件夹中打开终端,使用命令 bash -ex ./pkg2appimage recipes/OBS-Studio.yml 完成appimage的打包(过程较长,耐心等待)
  5. 完成。现在可以在 AppImages-master/out 下面找到刚刚打包好的appimage版本OBS了。

至此,新版本的OBS安装包制作完成。推流、录像都不再有问题了,美滋滋

KDE下不能启动deepin wine一直是个挺难受的事情。就我个人来说,喜欢KDE的桌面风格,但又不想放弃deepin wine里边比较优质的程序。所以想到了一个比较骚的招数,也算是解决了吧。

主要思路:可能是deepin-wine在打包时无意间加入了gnome依赖。所以补齐依赖就可以了。

方法很简单,安装gnome-settings-daemon

之后,将/etc/xdg/autostart/org.gnome.SettingsDaemon.XSettings.desktop 复制到 ~/.config/autostart/

最后,去往设置—开机和关机—自动启动 中,将gnome的一项勾选启动即可。

一直使用shadowsocks-qt5做ss客户端,之前在DDE下面也能方便的设置全局代理,但是到了KDE下,它的代理设置方法就没有那么方便了。所以在其他桌面下,一般在终端使用ss更好一些。但是这样一来,就没有一个图形界面可以使用了。而在网上能搜索到教程又少,好不容易找到qt5的又不成功,所以只能自己摸索了。不过还好,经过一番实验,终于在KDE下把qt5整成全局代理了,遂记录在此。

一、生成一份pac文件

这个的用处很明显,只代理不可访问的地址,以确保可访问的不绕路,不可访问的可联通。

  • 安装pip(如果系统未安装,需安装)
sudo apt-get install python-pip python-dev build-essential
sudo pip install --upgrade pip
sudo pip install --upgrade virtualenv
  • 安装Genepac以自动生成pac文件

sudo pip install genpac

  • 选择一个存放pac文件的文件夹,并生成

genpac --proxy="SOCKS5 127.0.0.1:1080" --gfwlist-proxy="SOCKS5 127.0.0.1:1080" -o 输出文件地址 --gfwlist-url="https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt"

pac文件就成功创建了。

二、KDE下设置代理

假设已经安装了shadowsocks-qt5且已经启动。现在只需要将其与全局代理和pac文件关联起来就完成了。

打开KDE的系统设置,切换到网络—设置—代理。

在“配置所用的代理服务器”窗口中,选择“使用手动配置的代理服务器”。

在弹出的表单中将“SOCK5代理”处添上 127.0.0.1,后面的“端口”填1080,“例外”处填写刚刚生成的pac文件位置,file:///开头(是三个斜线,如file:///home/kevin/proxy.pac)。

最后,勾选“只为排除列表中的地址使用代理服务器”,确认。

全局代理就设置好了。

得益于Linux较为缺陷的驱动程序们,Linux是比较费电的。这集中表现在电池的使用时间会明显短于Windows下面使用。但是借助一些电源管理软件,我们可以最大限度的提升Linux在电池情况下面使用的时长,甚至在相同工作量下面超过Windows。

比较好用的软件就是TLP。TLP提供优秀的Linux高级电源管理功能,不需要了解所有技术细节。默认配置已经对电池使用时间进行了优化,只要安装即可享受更长的使用时间。但如果想最大限度的优化电量损耗,还是需要自行进行配置。

在tlp更新到1.3后,配置文件结构有较大改动。下文会将新增/变更部分加粗表示,删除部分则直接加上删除线以区分。

一、相关软件包

一定需要安装的:tlp

无线设备控制:tlp-rdw

硬盘降速:smartmontools

CPU高级节能:x86_energy_perf_policy

网络唤醒更改:ethtool

对ThinkPad的电源优化:tp_smapi(充电阈值与电池校准)、acpi_call(Sandy Bridge及更新型号上面的充电阈值与电池校准)

二、服务调整

通过命令systemctl enable tlp(tlp-sleep服务已被移除)来启动TLP服务,并通过命令systemctl mask systemd-rfkill.servicesystemctl mask systemd-rfkill.socket来屏蔽systemd的rfkill服务及套接字以防止冲突,保证TLP无线设备的开关选项可以正确运行。

如果安装了tlp-rdw以便控制无线设备节能,则需通过systemctl enable NetworkManager-dispatcher启用此服务,并通过命令systemctl mask systemd-rfkill.servicesystemctl mask systemd-rfkill.socket来屏蔽systemd的rfkill服务及套接字以防止冲突,保证TLP无线设备的开关选项可以正确运行。

一般情况下都使用NetworkManager作为网络管理器。如果使用其他的,请编辑 /etc/systemd/system/multi-user.target.wants/tlp.service ,将 After=multi-user.target bluetooth.service NetworkManager.service 一行的 NetworkManager.service 去掉以避免错误。

现在,注销重新登录一下,默认配置的TLP就已经启动了。此时电脑消耗的电量应该比之前少了一些。但如果想要做到最大程度的节能,需要自行编辑一下TLP的配置文件。

三、配置文件的几个主要配置

用root权限的文本编辑器打开 /etc/default/tlp ,这是TLP的配置文件。

配置方式在1.3后变更较大。用户既可以修改/etc/tlp.conf,亦可以在/etc/tlp.d下以设置项=值的配置文件形式实现更改。该文件夹遵循下述规则:

  • 加载顺序受文件名最开始的数字影响,越大的数加载越晚,越能覆盖前面的设置
  • 00-template.conf为示例,用户自定义时亦需参考这个文件的命名方法和书写方式
  • 如果/etc/tlp.d下有些设置与/etc/tlp.conf冲突,则遵循tlp.d下的设置

推荐直接修改/etc/tlp.conf,因为这个文件的配置方法与以前的版本相同。下面的内容全部针对此文件。

每一项都是什么作用已经通过注释标记在这个文件中了。你可以根据自己的需要对相应的位置进行修改。但经过我自己的探索,给出几个自己最好改一改的位置。

1、TLP_DEFAULT_MODE

这一项记录了TLP启动时默认的模式。改成BAT可默认以电池供电方式启动,达到节省电量的目的。

2、TLP_PERSISTENT_DEFAULT

配合TLP_DEFAULT_MODE的修改,此处改成0以保证在连接电源线时电脑会以非节点模式运作以达到最高性能,而当改成电池供电,TLP自动将状态修改为节点模式以节约电量。

3、CPU_HWP_ON_AC和CPU_HWP_ON_BAT

使用Intel Skylake架构或更新的CPU并且Linux内核版本 >= 4.10可启用该配置。这两项分别对应通过电源连接和通过电池供电时候CPU的运作模式。可选performance, balance_performance, default, balance_power, power,依次为最高性能、优先考虑性能、默认、优先考虑节能、最大节能。

可以设置为CPU_HWP_ON_AC=balance_performance和CPU_HWP_ON_BAT=power可以保证电源供电时候偏好性能而电池供电时最大节能。

至于Skylake架构以前或Linux内核版本低于4.10时该配置失效,可忽略该项而将CPU_SCALING_GOVERNOR_ON_AC和CPU_SCALING_GOVERNOR_ON_BAT两项进行修改(如果有注释符则取消注释)。

对于酷睿i系列,可选项powersave和performance(推荐前者);其他型号可选项ondemand, powersave, performance, conservative, schedutil(推荐ondemand)

4、ENERGY_PERF_POLICY_ON_AC=performance和ENERGY_PERF_POLICY_ON_BAT=power

CPU相对节能策略。可选项performance, balance-performance, default, balance-power, power

5、DISK_DEVICES

该项关乎到之后的磁盘节能策略涉及到的磁盘。默认只有sda和sdb两块磁盘。如果你有更多的磁盘,请都加到引号内,通过空格分隔。磁盘label可以通过命令fdisk -l获得

如果此处修改了磁盘的数量,那么所有关于磁盘的设置项都需要对应的修改。如:

6、DISK_APM_LEVEL

这个设置意在调整硬盘在空闲时间节电,必要时候可以将低转速来实现。这里同样对应着AC和BAT。可以把AC设置成默认,即写为keep。注意,有几块磁盘写几个配置,中间通过空格分隔。如我有三块磁盘,DISK_DEVICES改为了"sda sdb sdc",则此处对应修改为"keep keep keep"

至于BAT一项,可以设置节电等级。其中1~127的节电等级可能会使硬盘降速,128~255则不会改变。因此对于SSD,设置128以上即可,HDD则可以设置成120左右的数字来兼顾唤醒延迟和降速节电。同样需要注意,在DISK_DEVICES写了几块硬盘,这里将要写几个参数。如我的三块硬盘,此处写成了"128 128 120"

7、SATA_LINKPWR

磁盘ALPM节电选项。同样对应着AC和BAT。

可选项min_power, med_power_with_dipm, medium_power, max_performance。其中,med_power_with_dipm需要4.15及以上版本的内核支持。

与6同理,有几块硬盘写几个配置,通过空格分开。如我的三块硬盘:

`SATA_LINKPWR_ON_AC="max_performance max_performance med_power_with_dipm"
SATA_LINKPWR_ON_BAT="min_power min_power min_power"`

8、RUNTIME_PM_BLACKLIST

如果使用bumblebee来控制英伟达显卡,那么把这一项的注释取消掉,然后在后面的引号中输入英伟达显卡的硬件地址以使Bumblebee控制GPU的电源。

获取硬件地址可以通过命令 lspci 来查看。一般情况下是 01:00.0

更多的设定还望自行阅读说明进行调整。如此设定之后,Linux在电池供电时,使用时间应该可以明显的提升了。

达芬奇是一款全平台支持的调色软件。现在加入了剪辑功能,再加上Fusion的助力,可以把这个软件当做一个强大的后期聚合软件来使用。但是官方对于Linux支持的定义只包括了CentOS,对于Debian系的说明并不明确。所以在尝试之后特地来记录一下其在Deepin(基于Debian sid)上面的安装过程

一、获取DaVinci Resolve

前往 https://www.blackmagicdesign.com/cn/products/davinciresolve/ 获取安装文件(.zip)。免费用户可以使用DaVinci Resolve,感觉对个人来说够用了。在点击下载之后填写一个表格即可得到链接。

二、补全依赖

DaVinci的依赖比较复杂。因此在安装之前请先调整好自己系统的依赖关系以满足DaVinci安装程序和运行的需要。

注:网络上有脚本可以把DaVinci的安装程序转换为.deb,安装更方便。最后讲。

需要事先安装的依赖命令如下:

sudo apt install libssl1.0.0 ocl-icd-opencl-dev

官方推荐安装NVIDIA的闭源驱动。因此对于核显以及AMD显卡的用户,可能会有不可预料的错误发生。

对于安装有NVIDIA闭源驱动的用户(bumblebee方案亦可),再追加以下命令:

sudo apt install nvidia-cuda-dev nvidia-opencl-icd

至此,依赖安装完毕。

三、安装DaVinci Resolve

将下载好的zip解压缩,得到一个.run文件。

在终端中通过 ./*.run 来运行得到的run文件(*对应解压出来的run文件名),一步步安装即可。

安装完成,如果是bumblebee用户,请通过optirun命令来启动。它的启动命令为

optirun /opt/resolve/bin/resolve

一般来讲,应该可以运行成功了。如果出现没有窗口打开的情况,请通过如下步骤检查:

  • 通过终端运行DaVinci (终端命令 /opt/resolve/bin/resolve ) 检查输出的错误信息
  • 确保所有的依赖都已安装。 运行 ldd /opt/resolve/bin/resolve 来查看是否有缺失的库文件 (对于找不到的依赖,ldd应该会在对应行显示空白对应关系)
  • 查看日志文件。位置在 /opt/resolve/logs/ ,有两个需要关注: ResolveDebug.txt rollinglog.txt
  • 确保CUDA和OpenCL安装成功,并且可以正常载入。即使使用CUDA,同样需要一个正常的OpenCL功能。
  • 如果在启动时便发生 Segmentation fault ,一般情况意味着缺失GPU驱动,或使用了不支持的GPU驱动程序或硬件。具体请查看 /opt/resolve/logs/

将.run编辑成.deb安装包进行安装

这很大程度上可以便于补全缺失的依赖 (通过 apt -f install 即可完成)。步骤如下:

  • 去往 https://www.danieltufvesson.com/makeresolvedeb 获取脚本文件。注意这里下载的脚本一定要与自己持有的DaVinci版本相对应。比如现在官网可以获取到15.2.2,则在这里请下载适配15.2.2版本中最新的脚本文件。
  • 补全所需依赖。使用命令 sudo apt install fakeroot xorriso
  • 将得到的 tar.gz 文件解压,文件放到 DaVinci 安装程序(.run文件)相同的文件夹下。这个文件夹一定要在ext4或其他默认权限为755的分区中(NTFS不支持Linux的权限管理,默认为777)
  • 在该文件夹下打开终端,输入 ./"脚本名" lite 完成deb文件的创建

对于Deepin来说,以上是全部过程了。如果在某些步骤中还有缺少依赖的提示,只需通过 sudo apt install 依赖名 补全即可。

文章来源:https://sspai.com/post/41302

为什么要考虑自己搭建 RSS 服务

Google Reader 在 2013 年的下线似乎标志着 RSS 黄金时代的结束。在那之后,虽然陆续出现过很多替代品,但 RSS 的地位已经被无限刷新的信息流、算法推荐等新技术逐渐取代了。

不过,尽管小众,RSS 仍然是不少极客用户获取信息的首选。的确,如果对信息来源要求苛刻且善加维护,RSS 仍然是高效获取信息的不二选择。当然,为了充分发挥 RSS 的优势,一个好用的 RSS 服务也是很重要的。但是,「好」的标准又是什么呢?

在多年日常将 RSS 作为主要信息来源之一、并尝试了多种主流的 RSS 服务之后,我认为一个合格的 RSS 服务应当满足下列要求:

  • 同步及时;
  • 订阅源管理便捷、支持导入/导出;
  • 设计简洁、适合阅读、可定制;
  • 客户端支持全面;
  • 可自定过滤规则。

对于上述需求中的前几项,目前常见的 RSS 服务各有侧重。例如,最常见的 Feedly 在界面美观程度上较为突出,而 Inoreader 则在订阅源的管理上功能更为全面等,但并不存在一个全能选手。而至于最后一项需求,即自定规则对文章进行过滤,这些主流服务就显得特别「吝啬」了,要么不提供这样的功能,要么作为收费服务额外提供。

这当然可以理解:过滤功能需要占用额外的计算资源,这对原本就属小众的 RSS 服务来说是一笔不小的额外开销。但即便如此,仅仅为了实现这样一个并不算复杂的需求,而每月花数美元的价格(Inoreader 高级版年费为 30 美元),未免让人感到有些不值得。

相比之下,虚拟服务器如今已经卖到了白菜价。国外主流的平价主机商在竞争压力下,纷纷推出了低至 5 美元甚至 2.5 美元月付的计划;而国内的互联网大厂则在「云计算」的热潮中,竞相对自家的「云主机」进行优惠促销,其中面向学生的优惠往往可低至 10 元。这就在价格上追平甚至优惠于上述 RSS 服务的定价。

更何况,一台服务器运行的是完整的 Linux 操作系统,其功能用途远不止于搭建 RSS 服务一项,在类似的价格下,性价比可谓完胜;对于注重隐私的用户来说,自建服务附带地带来的安全性也是附加值之一。可见,用订阅 RSS 高级服务的费用投资一台虚拟服务器并自己实现类似功能是非常可行的选择——这正是我们今天的主题。

(关于主机服务商的选择,本文无意讨论,网络上有很多评测信息可供参考,请根据自己的需求和网络环境选择。主机的内存最好在 512 MB 以上,且必须采用 KVM 架构。如果你订阅的国外 RSS 源偏多,请注意国内主机的网络可能不能胜任。

为什么选择 Docker 下的 Tiny Tiny RSS

如果要为了实现 RSS 功能而自己从头造一个轮子,那必然是一个不现实也不经济的选择。事实上,开源社区已经为我们提供了许多现成的解决方案,只要选择一个并将其安装到主机上,即可快速搭建起自己的 RSS 服务。目前,比较完善、处于活跃开发状态的开源方案当属 Tiny Tiny RSS,它基本满足了前面提到的各项鉴别标准,后文也将以其为例演示。

关于安装方式,固然可以选择像对待普通 Linux 软件那样直接安装,官方对此也提供了较为详细的文档,但本文更推荐使用镜像方式安装 Tiny Tiny RSS。

如果你还不了解 Docker,可以简单将其理解为一种模块化的安装方式:它既具有虚拟机方式安装软件的一些长处,如对安装和卸载对宿主系统影响小、软件之间相对隔离、安全性佳等,又保留了普通方式安装软件的优点,如资源消耗较小、软件间通信较为方便等。因此,Docker 方式安装是软件「尝鲜」相当合适的选择。另外,如果你是 iOS 用户,更有 HyperApp 这样便捷的可视化工具辅助 Docker 环境的配置和管理。

1. 安装

用 Docker 方式安装 Tiny Tiny RSS 需要的软件条件是:

  • Docker CE:用于提供 Docker 运行环境。
  • PostgreSQL/MySQL 数据库:用于存储 RSS 服务运行所需的记录。Tiny Tiny RSS 的作者推荐优先选用 PostgreSQL,以获得更好的性能。
  • Tiny Tiny RSS 本身

需要指出的是,Linux 下安装软件的途径是相当灵活的,在软件源、发行版本、使用命令乃至前后顺序上都有不同程度自由裁量的空间。因此,下面的安装步骤仅为示例,目的是用最少的步骤实现安装,并假定读者和笔者一样,理解浅显的 Linux 命令含义、但并不熟悉复杂或具体的技术细节。

首先,SSH 到你的主机,安装 Docker 环境:

curl https://get.docker.io/ | sh

如果你的主机位于国内,则使用上述脚本安装 Docker 可能较慢。为此,可以换用 DaoCloud 提供的、换用了国内镜像的安装脚本:

curl -sSL https://get.daocloud.io/docker | sh

之后,安装一个 PostgreSQL 的 Docker 镜像:

docker run -d --name ttrssdb nornagon/postgres

(请注意上述 PostgreSQL 镜像并非官方提供,在此选用的原因是其预先配置好了可以直接配合下述 Tiny Tiny RSS 镜像使用的数据库环境,无须进一步设置。)

最后,安装 Tiny Tiny RSS 本身的 Docker 镜像:
:
docker run -d --link ttrssdb:db -p 80:80 -e SELF_URL_PATH=http://example.org/ttrss fischerman/docker-ttrss

上述命令中的一些关键部分:

  • -p 80:80 : 该参数表明,将该容器内应用的 80 端口(冒号后)映射到主机的 80 端口(冒号前)上。如果你的主机还需运行其他 80 端口的服务(如博客建站),则应将冒号前的值改为一个未被占用的端口。例如, -p 8080:80 将启用主机的 8080 端口。
  • -e SELF_URL_PATH=http://example.org/ttrss  :该参数表明,该 Tiny Tiny RSS 应用将可从 http://example.org/ttrss 访问。如果你在上一步保持了默认的端口设置,则直接将上述网址换为你主机的 IP 地址(或解析至该主机的域名)即可,否则,应在地址之后进一步表明使用的端口,如: http://xxx.xxx.xxx.xxx:8080

2. 基本使用

2.1 初次配置

安装完成后,访问在上述步骤中设置的网址,即可进入 Tiny Tiny RSS 的 Web 界面。系统默认的管理员账号是 admin ,密码是 password

登录后,首先点击 右上角的 Actions…>Preferences… 进入设置页面,进行一些基本配置。

  • ersonal data / Authentication 板块:登录后应立即在此设置新密码
  • Preference 板块:

    • Default feed update interval:设置刷新订阅源的时间间隔,应根据自己查看 RSS 的频率和服务器的性能合理安排。考虑到 RSS 一般无须即时性,一般最短 30 分钟的间隔足矣。
    • Enable API access:提供第三方 RSS 客户端支持,务必勾选
    • Language:语言设置,其中包括简体中文,但翻译质量和完成度均不佳,故本文仍以英文界面为准。
    • Purge articles after this number of days:在指定日期后清除缓存的文章。考虑到目前主流主机服务均以小容量 SSD 存储为主,应合理设置此处期间,以避免占用过多空间,如 30 日。
    • Time zone:设置时区,国内一般设为Asia/Shanghai即可。
    • Combined feed display:设置阅读界面布局。默认为两栏式,点击文章列表中的标题后,全文将在标题下展开。如习惯 Reeder 一类传统 RSS 客户端的三栏式布局,取消该项勾选。

完成后,点击页面底部的Save configuration保存配置。

2.2 导入、添加和管理订阅

如果你之前使用过其他 RSS 服务,那么直接将订阅源导入即可。方法是:在之前的 RSS 服务后台找到导出为 XML/OPML 的选项,然后在 Tiny Tiny RSS 中进入设置的Feeds标签页下的OPML板块,选择相应文件导入即可。原有的文件夹结构会被保留。

导入后,可在Feeds标签页管理订阅源。Tiny Tiny RSS 提供的管理选项非常详尽,并可以通过拖动来实现排序、分类操作。点击某个订阅源,可以打开更详尽的设置选项。其中比较实用的功能包括自定义订阅源名称、更新频率等。

此外,Tiny Tiny RSS 还提供了一些用于辨识订阅源「健康度」的实用功能。如果有某些订阅源无法连接或长期不更新,那么订阅页面中会分别多出Feed with errorsInactive feeds的选项,点击即可查看这些订阅源的出错记录或最后更新时间,并直接批量退订。

2.3 文章过滤

如前所述,强大的过滤功能是促使笔者转投 Tiny Tiny RSS 的首要动力,也是高效处理大量 RSS 订阅源的重要工具之一。Tiny Tiny RSS 的过滤功能分为匹配动作两个环节,即先根据一定的规则筛出特定文章,然后自动对其实行某种处理。前后两个环节都是可以高度自定义的。

在设置页面中,点击Filters标签即可进入过滤设置。首先通过Create filter按钮新建一个过滤器。弹出的窗口中,Caption部分用于指定规则的名称,Match部分用于设置匹配规则,而Apply actions部分则指对被匹配的文章应采取何种操作。

点击Match部分的Add按钮即可添加匹配规则。你可以指定匹配标题、全文还是两者均匹配,每个匹配规则适用于哪些订阅源。匹配规则支持正则表达式,例如,如果想过滤英文科技博客中常见的赞助广告,那么可以在过滤规则中填入 (S|s)opnsor 这样含有「sponsor」或「Sponsor」的结果都会被匹配。同一个过滤器中可以容纳多个匹配规则,多个规则间默认是相「与」的关系,如果想改为「或」的关系,则须勾选窗口下方的Match any rule

对于被筛出的文章,可以选择的操作很多,如标为已读、完全忽略、打上星标等等,并且可以同时适用多个操作。一个比较有趣的操作是Publish article,它会将文章发布到一个 RSS 源中(该 RSS 地址可在Feeds选项卡的Published & shared articles区域看到)。进而,结合 IFTTT、即刻等支持检测特定 RSS 源更新的服务,就可实现特定主题实时推送、自动发送到稍后读等高级功能。

不过,过滤功能是比较消耗资源的,如果设置过多的过滤条件,可能给你的主机带来较大压力,因此不应滥用该功能。换个角度来说,当你发现自己将精力不成比例地花在过滤功能上、而非静心阅读文章上时,最应该做的应该不是继续调试过滤、而是清理订阅源。

3. 用插件添加主题、全文输出和多客户端支持

3.1 安装主题

前面提到,RSS 服务质量的衡量尺度之一即是界面的设计水平。在这方面,Tiny Tiny RSS 只能说是基本合格:其界面虽然功能全面、且总体上可称之为简洁明了,但细看还是给人一种开源软件常有的「未经打磨」之感。好在 Tiny Tiny RSS 的界面完全基于 CSS,可自行定制或导入主题,这就为「美容」提供了可能。

Tiny Tiny RSS 用户社区产生的主题并不多,但也有不乏几个完成度较高的,如仿 Feedly 和仿 Google Reader 的两个主题。下面以前者为例演示如何安装。

首先获取主题文件:

wget https://github.com/levito/tt-rss-feedly-theme/archive/master.zip

然后解压缩该主题[1]:

unzip master.zip

由于我们的 Tiny Tiny RSS 运行在相对隔离的 Docker 环境中,因此不能像平时那样直接用 cp 命令拷贝文件。为此,首先执行:

docker ps

终端将返回当前运行的 Docker 容器列表。我们找到 IMAGE 一列为「fischerman/docker-ttrss」的那行记录,记下同行中 CONTAINER ID 列下的内容。

然后,用docker cp命令将上述主题文件拷贝到容器中:

docker cp tt-rss-feedly-theme-master/feedly.css [[CONTAINER ID]]:/var/www/themes
docker cp tt-rss-feedly-theme-master/feedly [[CONTAINER ID]]:/var/www/themes

请注意将上面命令中的[[CONTAINER ID]]替换为你在上一步中获得的内容。

这时,我们就可以在 Preference 页面的 Theme 选项中看到feedly.css了。

3.2 配置 RSS 全文输出

很多网站之所以不欢迎 RSS,一个主要的原因就是提供 RSS 会分走主站的流量;因此,一些网站即便保留了 RSS 订阅源,也做得十分「不情不愿」,只「抠门」地给出前两三段的内容,要看全文还得跳转到网站才行。这显然会破坏 RSS 的阅读体验。于是,获取全文的功能就显得十分必要了;很多 RSS 服务或客户端也将其作为 Premium 订阅的卖点之一。不过,通过 Tiny Tiny RSS,我们同样可以免费实现这一效果。

事实上,Tiny Tiny RSS 原本已经内置了基于 Readability 的全文输出服务,但可惜这家服务在前段时间已经跑路,关闭了 API 接口,我们只能另请高明。目前,比较好的替代方案是 Mercury,这也是 Reeder、Unread 等主流 RSS 阅读器在近期更新中改用的方案。

首先,Mercury 的全文输出服务是免费的,但需要配合 API 密钥使用,这可以在注册后在其网站的 Web Parser 页面看到。

接着,为 Tiny Tiny RSS 安装全文输出插件,其方法与安装主题完全相同[2]:

git clone https://github.com/WangQiru/mercury_fulltext.git
docker cp mercury_fulltext [[CONTAINER ID]]:/var/www/plugins

安装后,到 Tiny Tiny RSS 的设置页面中启用名为fulltext的插件。这时,在设置页面的Feeds选项卡下,就会多出一个该插件的设置区域。我们将之前获得的 Mercury API 密钥填入文本框中,并点击Save保存配置。

完成上述准备工作后,就可以针对特定的订阅源启用全文输出了。方法是:在订阅源管理中,点击需要获取全文的订阅源,在弹出的Edit Feed对话框中,勾选Plugins选项卡中的Get fulltext via Mercury Parser

3.3 让更多客户端支持 Tiny Tiny RSS

在 RSS 的使用体验中,客户端是十分重要的一环;缺少第三方客户端支持的 RSS 服务注定只能是「孤家寡人」。然而,作为一个小众的开源软件,Tiny Tiny RSS 在这方面显然不能与那些商业服务相比。主流的客户端软件中,只有 Fiery Feed 提供了对 Tiny Tiny RSS 的原生支持。

好在开放的插件系统这时再次发挥了作用。借助第三方插件,Tiny Tiny RSS 可以将自己模拟为另一个自建 RSS 工具——Fever,而后者的客户端支持更为全面,包括 Reeder、Unread 等。[3]

git clonehttps://github.com/rannen/tinytinyrss-fever-plugin.git
docker cp fever [[CONTAINER ID]]:/var/www/plugins

安装后,在 Tiny Tiny RSS 的设置页面启用名为fever的插件。保存后,再次进入设置时,Preference选项卡下会多出一个名为Fever Emulation的板块。在该板块的文本框中,设置一个专用于该插件的密码,然后点击Save。该文本框下方同时给出了一个独立的服务器地址,其格式类似于http://rss.example.org/plugins/fever/。将其记下以备后用。

4. 总结

以上就是使用 Tiny Tiny RSS 自建 RSS 服务的全过程。可以看出,虽然听起来很 geeky,但实际操作比想象的简单很多,稍微熟悉后不到半个小时就可架起服务并使用。从我两个月的使用体验看,它基本已经完全代替了之前对 Feedly 和 Inoreader 的需求,且无论是灵活性还是性价比都是第三方服务无法比拟的。

当然,一旦涉及到这种 DIY 操作,总是要回应的质疑是:这么做值得吗?毕竟,「RSS 已死」不是什么新鲜论调了。这么说的人中,有的是 RSS 曾经的忠实用户,感慨曾经活跃的第三方软件和服务逐渐冷却;有的是新世代新闻、阅读服务的开发者,鄙弃 RSS 的老旧和刻板。

然而,RSS 说到底是一个协议。而协议只在一种情况下可以被宣告死亡:再也没有人使用的时候。诚然,如果只论 RSS 最「原教旨」的形态,其占有率确实几乎可以忽略不计了;但当下那些看起来更「现代」的资讯工具,尽管可以在界面、交互上不断翻新,但其本质仍然是一个时间线上的信息流,其中每篇内容包含的要素仍然是标题、时间、正文等 RSS 已经涵盖的要素。易言之,它们归根结底都是 RSS 的衍生物。从这个角度看,RSS 没有死、也不会死。

必须承认,新技术加持下的现代工具在配置和使用上都远比 RSS 来得便利和舒适。但,在获得便利的同时,你也将选择的权利让渡给了机器,将偏好和隐私让渡给了第三方;在追求舒适的另一面,是被无限信息流淹没的宝贵时间,和被算法推荐不断强化的「回音壁」效应。相反,RSS 是有限的,因此也是克制的;是刻板的,因此也是高效的;是不智能的,因此也是包容的。

在今天,坚持使用 RSS,能让你真正认真思考自己对信息的需求,在喧闹而充满误导和诱惑的信息海洋中守住自己对信息获取的控制权;而自建 RSS 服务,则是维护这种控制权的终极途径。


注:

  • 有的系统可能没有安装unzip命令,这时可先运行apt-get unzip安装该功能。
  • 要运行git命令,你的主机需要先安装git;如果运行时提示未安装,请使用apt-get git -all命令来安装。
  • 遗憾的是,Fever 也在去年圣诞节前夜跑路了,这也是它没有成为本文主角的原因。