飞蚊话 发布的文章

视频点此

一个很简单的想法,源于我的KDE桌面——要知道,我的KDE桌面壁纸设置的就是每日一图,bing来源。

思路也很简单。现如今iOS系统已经预置了一个十分方便但异常强大的组件:快捷指令,而根据KDE可以使用bing每日一图来推断,便可知道bing的图片接口是开放的。所以前提条件都准备好了,就直接来编写快捷指令吧。

打开快捷指令,新建。

首先就是要获取bing当天推荐的图片。而获取的方法自然是通过Bing提供的API获取。

API地址如下:https://cn.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1

快捷指令中已经提供了从API获取js结果的功能,直接搜索添加获取URL内容,其中获取来源填入上面的API地址即可。

从这个网址获取到的结果是一个json字符。在快捷指令中,可以很方便的将json串转换为词典并从词典中提取指定键对应的值。而这也是作为互联网上面API使用最多的数据传输方法。上述Bing的API得到的json保存有很多信息。而我们只需要其中的图片路径即可。假定上述获取到的json命名为Bing,那么它有关图片地址的键就在Bing.images.url。而这个路径并不是完整的,它没有保存这个图片对应的通用的网址前缀。而这个前缀就是Bing的网址https://www.bing.com/

在了解了上述规律之后,就可以继续完成这个快捷指令了。我们现在只是拿到了最初始的json字符串,接下来就是要解析并获取真正的图片了。而这些功能快捷指令都有着对应的功能。

增加一个功能获取词典值,来源位置会自动加入前一步骤得到的结果(URL的内容),也就是刚刚通过API获取的json。而为了之后简化路径,可以在这里先进行一次筛选,使之后的选择可以以Bing.images中进行。

点击URL的内容,弹出的小窗口中,类型(第二行蓝字位置)选择词典

下方获取键对应的值输入images,完成。这样变把此处的来源变成Bing.images里的内容了。

这个功能的后方,输入网址对应的键名url,获取的是

设置完成后这个功能整体表现出来的是这样的:

得到了URL,现在就可以补全URL来获取图片了。但是要注意,这里还是通过网址来获取的,所以使用的功能仍然是获取URL内容,而路径要输入完成的,补全的路径。因此需要在默认填入的词典值前面加上通用前缀https://www.bing.com/。整体看起来是这样的

最后,把获取到的墙纸设置为得到的图片即可。添加一个操作,名为设定墙纸,根据自己的需要,选择设置锁定界面还是主界面,而来源里边默认加入的URL的内容要注意,因为获取到的是图片,所以需要把类型设置为图像。如图。

同时,展开这个功能折叠的内容,关闭显示预览(否则执行后会进入到设定壁纸的预览界面,手工确定才能完成,就不符合原始的需要了。

视频点此

苹果家族的软件以封闭闻名,但macOS是一个例外——毕竟历史原因使得它除了图形界面以外都有规律可循。所以当使用Linux的思维去理解macOS的时候,就发现了一些到目前为止都没见过有谁提到过的有趣的细节。

我曾经在以前的内容中说过神奇的快捷方式——软链接。当时我就说过这玩意儿在Windows下用处不多,但Linux和macOS下用途很广。那时候我说这句话其实还是有些心虚的,因为我只用过Linux,对macOS的情况不是很了解,仅仅是为Linux和macOS的内核相似才得出的那个结论。但现在不一样了,我真正使用过macOS了,所以对于这个结论,我只能说:macOS同样很频繁的在使用软链接,可能比Linux更甚。

因为它为每个程序都软连接出来了一整套用户根目录,形成了一种沙盒机制。

我们可以简单领略一下:在home文件夹,打开资源库——你可能过需要按下cmd+shift+.来显示这个文件夹,或通过显示设置使它取消隐藏属性。

打开资源库,你会看到一个名字为Containers的文件夹。顾名思义,这里是用户程序的容器集合。打开它,你便能看到很多熟悉的面孔。

如果你有兴趣的话可以把每个文件夹都打开看看。这里我就直接跟你说结论吧:这里边一个文件夹就是macOS为一个程序准备的一个沙盒——或者说,一套用户home。为什么这么说呢?我们随意打开一个你就会看到。

是不是很熟悉?是的,这里边的文件夹结构与home是一模一样的,只不过这里多了Library、SystemData和tmp。

但是还是有些许不同的地方。注意到有几个文件夹左下角的小箭头了吗?错了,它不是普通的快捷方式,而是软链接。我们通过终端来看一下它们连接到的具体位置。

没有错,这些软连接都指向了我们的home。具体来解释一下:桌面、下载、视频、音乐、图片四个文件夹是与用户目录同步的,而文档、库、系统数据、临时文件每个程序都是单独占有的。这就使得在程序看来,自己是这个系统上唯一的程序,还可以在这个系统里边随意玩耍;而在macOS系统看来,每个程序就算玩出天来,也没能逃脱分配给它的这个乌托邦中。莫名的让我想到了缸中之脑理论…

那么如此设计的优势在哪儿呢?就我个人的感受,相对于另外两种系统来说,如此存储使得每个程序都有着相对隔离的系统环境,最大程度的避免依赖问题——任何系统都需要依赖,不只是Linux;而且所有文件都建立在了一个统一的位置,当卸载软件时直接删除这个文件夹便清理掉了由这个软件带来的所有文件——当然,音视频文档会保留,因为是软链接到了用户目录下。而与之相对的,就用户或者系统的视角来看,想去到一个程序的目录下路径就会变得异常复杂,以至于如果不耐下心来找的话会很难找到。

不过,既然找到了,就可以进行一些骚操作了。比如说微信电脑端、QQ电脑端的无限期云端同步功能。

视频点此

可能你想不到,我一直订阅着个人版的Office365,所以我拥有1T的onedrive存储空间。说实话,我一直想不到这么大的空间能用来干啥,直到我看到了我这个树莓派做的局域网文件中心。
为何不外挂上onedrive,整一个异地备份呢?

实现这个系统的关键其实就有一点:在树莓派上安装onedrive。我尝试过一些开源onedrive程序,但要么不支持arm架构,要么安装很繁琐。所以最终我跳出了花里鼓哨的onedrive客户端,转向了rclone——一个支持将很多协议映射成本地目录的神奇的软件。直接从源中安装即可。

安装好后,输入命令rclone authorize “onedrive”,会打开浏览器进入登录界面,登录成功后终端会返回token,保存好。

接下来,通过命令rclone config来根据向导进行配置,按照提示输入操作即可。只需注意最开始要输入一个名称,这个名称指代了网络硬盘,以后挂载时会使用到这个名字,所以要记住。同时,不需要选择高级设置,以及在最后登录一步的时候选择手动配置,将刚刚保存的token完全复制到终端即可。

现在,就可以通过命令rclone mount 名字: 挂载点 —daemon把你的onedrive挂载到本地了。这个挂载点完全指向了onedrive的目录,任何复制到这里的文件都将被直接上传到onedrive中。换句话说,复制进这个文件夹的文件将不再占用本地的磁盘空间,而是直接进入到onedrive之中。

测试无误后,我们将这条命令设置为开机启动。但是我发现通常方法,也就是在rc.local中加入语句并不能实现开机自启,所以这里也介绍一下设置开机启动的方法。

~/.config下新建autostart文件夹,其中新建一个.desktop文件,文件名随意。其中输入如下文本。

[Desktop Entry] 
Type=Application 
Exec=lxterminal -e “刚才那一串挂载指令”
Name=随便一个名字
Comment=随便一些注释

这就为rclone挂载命令建立了一个自动启动文件。以后无论何时启动树莓派,rclone都会把onedrive挂载到指定的文件夹中。受到一些小伙伴的提示,如此自启动可能只有把树莓派设置为使用gui且自动登录时候才会生效。要注意。

之后进行双向同步操作。我这里直接简单粗暴的通过计划任务加bash脚本来实现,一个负责从本地拷贝到远程(也就是挂载了onedrive的那个文件夹),一个负责从远程拷贝回本地。而本地目录是一个特定的目录,所有想同步到onedrive上的文件夹通过软链接的方式放到这个文件夹中。

到此,我的这个双点同步系统就搭建完成了。

相关视频:OBSAUR

这个文章只是简要介绍一下使用OBS构建软件包的基本方法,以及AUR与OBS在编写时候的对应关系。编写一个规范且更易维护的软件包要比这里边提到的关注点要多。

一、什么是OBS

开放构建服务Open Build Service)是一个通用的系统,以自动、连贯和可重复的方式从源代码构建和分发软件包。它可以为各种操作系统和硬件架构发布软件。我们用来构建发行版的 OBS 参考服务器目前(2018 年 6 月)已有 53219 个项目,其中包含了 79794 个仓库中的 468316 个软件包,用于众多发行版和架构,并由 53171 个已确认的开发者使用。

资料来源于Portal:构建服务 - openSUSE Wiki

二、什么是AUR

Arch 用户软件仓库(Arch User Repository,AUR)是为用户而建、由用户主导的 Arch 软件仓库。AUR 中的软件包以软件包生成脚本(PKGBUILD))的形式提供,用户自己通过 makepkg) 生成包,再由 pacman) 安装。创建 AUR 的初衷是方便用户维护和分享新软件包,并由官方定期从中挑选软件包进入 community 仓库。许多官方仓库软件包都来自 AUR。通过 AUR,大家相互分享新的软件包生成脚本(PKGBUILD) 和其他相关文件)。用户还可以为软件包投票。如果一个软件包投票足够多、没有协议问题、打包质量好,那么它就很有希望被收录进官方 community 仓库(以后就可以直接通过 pacmanabs 安装了)。

资料来源于Arch User Repository(简体中文)

三、快速通过OBS构建一个软件包

以我打包的electron-wechat为例。

一切的基础,是需要你拥有一个OBS账号并登录。前往OBS官网注册并登录,你就拥有你的工作空间了。

通过Create Package,来创建一个软件包目录,并将源码上传到这个目录中。但要注意的是,OBS构建的服务器是不联网的,所以对于electron-wechat这种nodejs的程序,由于通过npm命令进行构建的时候一定会去往nodejs官网检索相关依赖的最新版本,所以对于这种程序,最简单的办法就是直接上传编译好的文件进行分发。


这里想补充一下:已经在自己的电脑上编译好了,那就已经可以使用了,为啥还要使用OBS打包呢?很简单,因为自己编译出来的东西是零散的,需要手工把文件放到对应的位置上去,而且没有一个统一的卸载方法。通过OBS打包之后,就可以进入到软件源中,直接通过统一的安装/卸载指令来使用一个软件了。


所以对于electron-wechat,我就是在本地编译好了之后,将二进制文件打包成tar.bz2,上传到了打包目录。

之后,编写spec文件。这个文件告诉了OBS到底都需要干什么来完成打包。

在打包目录下新建软件包名.spec,开始填空。(如果使用openSUSE的vi编辑器直接新建的话,会直接生成一个.spec文件的模板,填空即可。)

  • Name: 软件包名
  • Version: 软件包版本
  • Release: 使用默认即可
  • Summary: 一句话介绍
  • License: 许可证类型
  • Group: 软件类别
  • Url: 项目地址
  • Source: 源码地址

    如果有多个源码,可以通过Source0 Source1 依次指定。参考我打包的dingtalk

  • Provides: 提供的内容
  • Obsoletes: 排斥的内容

然后,在%description下写一个比较详细的软件介绍,不主要的部分就写完了。

之后,%prep下写入打包要做的准备工作。比如解压缩源码包。对于以软件包名-版本号.tar.bz2形式的包,默认的%setup -q即可完成解压。其他命名方法的bz2,需要补充 -n 参数。即setup -q -n 包名

如果还有其他要解压之类的工作,一并写在这个下面,可以参考rpm打包的宏,如果不熟悉,也可以使用bash命令代替。

准备工作做好,填写%build编译部分。对于一般的C语言,可以上传源码包,在%build填写编译的指令。而对于nodejs这种无法通过编译的软件,由于上传的就是编译好的二进制文件,所以编译这部分留空。

%install指示了编译出来的所有文件都要放到什么地方。这里相对比较简单理解,就是通过bash命令,把编译出来的文件依次复制到它应该在的位置即可。至于具体应该在什么位置,就要看一看Linux的标准了。如果不确定的话,把所有文件放在/opt/软件名这个文件夹下也未尝不可。这种做法并不标准,但很快。不过即使如此操作,也需要注意desktop桌面入口文件和图标文件一定要放置在它应该在的位置,否则在图形界面一定会找不到启动的按钮,图标显示也会有问题。
%post -p /sbin/ldconfig%postun -p /sbin/ldconfig两句话照抄即可。

之后,在%files下书写这个软件都拥有哪些文件和文件夹。宗旨就是产生了哪些文件,就把绝对路径写在这里。

到此,一个简易的spec文件就写好了。

之后的查错,可以通过OBS编译结果进行排查,根据报错进行修改即可。

四、AUR编写与OBS的异同

AUR与OBS非常类似,区别只在于OBS的spec文件命名是根据软件包名命名的,而AUR的文件叫做PKGBUILD。所以在AUR建立一个软件工程后,直接新建一个PKGBUILD,在里边编写即可。

至于编写的内容,与OBS也很类似,只不过AUR是一个更纯粹的脚本,不能使用OBS里边诸如%prep这种宏来书写。

我的OBS仓库的dingtalk就是借鉴AUR的dingtalk-linux。可以对比着来看一看。

相对来说,AUR的编写更容易上手,但是相对OBS来说,编写出来的PKGBUILD通用性会差一些。不过无论哪种,思路都是类似的。看一看现有的文件写法,自己尝试一下就会了。

前些日子尝试通过电报来实现短信多终端同步的方案,很成功,并且为了实验稳定性开了一天。到了第二天早晨再看,服务是正常的。但新来的短信就是没再往Tg上面发送。

最先想到的就是梯子有问题了,通过尝试也发现确实是梯子的问题。具体表现就是浏览器会报503错误。

现在使用的是v2ray方法,在刚搭建好的时候也遇到过503问题,所以惯性的认为这次出现这个问题也是由于服务器时间与本地时间不一致导致的(服务器商授时比实际时间快了3分钟,不知道什么毛病)。

不过当我查看服务器时间时候,发现问题好像没那么简单了——因为服务器时间很正常,说明并不是时间出错导致的这个问题——一下子就感觉问题严重了起来。

查看服务状态(systemctl status v2ray),是active,一切如常;查看运行日志(/var/log/v2ray/access.log),一大溜的invalid user。这是认证错误;但是我并没有改过我的config文件(/etc/v2ray/config.json)啊,为什么会失效呢?

上网搜索类似的情况,并没有什么有用的解答。不过在网上冲浪的过程中,v2ray的github页面提交issue的模板让我想到了一个可能的原因:

  • 我的安卓机应用是play商店自动更新的
  • 我的iOS应用是商店自动更新的
  • 我的Archlinux是及时跟进版本的
  • 我的openSUSE刚刚做了一次dup,所有存在新版本的软件都升级到了最新

这些都指向了一个可能的原因:版本不同(github上面就写到了如果客户端和服务端版本不同请注明)。我的客户端全部到了最新而服务端已经很久没有更新过了。

所以先尝试把服务端更新到了最新,再次尝试。

仍然503.

这就真让我百思不得其解了。

不过在查看服务状态时,有一行信息引起了我的注意:它提示读取的配置文件路径是/usr/local/etc/v2ray/config.json

咦?跟网上大多数提到的/etc/v2ray/config.json不一样啊。查看了一下usr的配置文件,里边只有一行:

{}

这就很好的解释了为啥认证会失败了。啥配置都没有,能存在有效用户就怪了。

虽然不知道为什么之前的/etc/v2ray/config.json可以生效,但既然它现在貌似读取的是带usr的路径,那给它补上就得了呗。

不过为了延续之前的路径,做一个软连接可能是更恰当的选择。直接ln -s /etc/v2ray/config.json /usr/local/etc/v2ray——当然,提前把usr那个空的config文件删掉。

尝试重启服务systemctl restart v2ray,查看状态……

退出。

不过下面的信息给出了明确的信息:日志文件无法写入。

那就把日志文件的读写权限给上去就得了呗chmod 666 /var/log/v2ray/*

再次启动服务,成功。尝试通过客户端连接,也成功了。


这问题出现的还挺突然的——因为前一天还是可以正常使用的东西,在啥都没手工动过的情况下就不能用了,还是非常没有头绪去解决的。不过好在没有什么特别令人费解的问题(虽然突然间读取的配置文件路径就变了有些令人费解),很快也就解决掉了。但关键在于网上竟然没有一篇文章能适配到这个问题上,所以还是写下来了。

好像很长时间没怎么更新过博客了,就连一些评论也没再回复过。

所以趁着元旦有点时间,简单说说吧。

工作了

去年8月份开始,正式从学生变成了社会人。不好说是否已经完成了身份的改变,但这身份终究是要如此转变的。

我现在就职在某国企的系统集成子公司的总部。不用想,肯定有很多人感觉朝九晚五,工作轻松。

错了。因为它早在3年前就已经进行了混改了,现实的情况是在我去之前,我们组一共4个人,要支撑全国31家分公司和产业互联网公司的业务。你就可以想象一下在总部的这几个人需要拥有多少个分身了。

但现实终究不是西游记,这些人也不可能拥有分身来协助,所以纵使刚刚到岗的我再不熟悉业务,也算是多了一个帮手。什么意思呢?我到岗的第4天就被安排出差去四川了。

从四川回来,是为期一个礼拜的新员工培训——这可能也是我这半年里边最轻松的一个礼拜。

然后便是无止境的工作。对了,我好像还没有介绍公司的上下班时间:早上八点半,晚上五点,不打卡。

但是工作量使得五点这个下班时间没有什么作用,至少从五点半开始,同事才会陆陆续续的离开。

可能即使是这种程度的加班也比一般的互联网公司下班时间早。但是要知道,公司是不打卡的,不打卡就意味着人力或者领导并不知道你到底是几点离岗的,也就意味着加班是没有加班工资的。

退一万步讲,即使我可以做到正点下班,我的单位在二环里,每天我都要往返于六环外和二环里。而这就使得我一天要上两个班:单位一个班,坐车一个班。

说几个数据你可以体会一下:为了保证八点半到岗,我需要赶六点四十五的车上班;五点半出公司的话,我最早可以在八点二十下车到家。

插空做的视频

所以即使正点出公司,我也没有时间在工作日做视频。所以从工作开始,所有的视频都是在礼拜六日抽空录制的。这也是为什么我不再提供字幕了。没时间打轴维护,也懒得在休息日做这么多工作了。

如果你是从b站关注过来的,你应该还记得我在去年八月份时候发过一条动态,就是更新频率从周更调整至四周三更。这是有计算的。因为我知道不管我去到什么样的公司,我家的位置也就保证了我在工作日是没有时间做额外的事情的——有时间也只是在坐车途中看看书。所以所有额外的工作都要堆到周末完成。而一个月有四个礼拜,四周三更就意味着每个月能空出来一个星期。我又没指定四周三更是哪三周更,所以这一个礼拜有着很大的价值:

  • 如果这个月没什么出差也没什么事,那么空出来的这个礼拜可以录一个视频做备用。
  • 如果有出差,那么出差占用的那个礼拜末正好就是四周三更中不更新的那一周,或者直接使用备用视频发布。

事实上也是这样。在这半年里,我已经使用过几个备用视频了,你可以通过结尾来判断。

很少更新的博客

这半年里边,我视频内容更多的是在进行看板主题的解答。这一部分的内容我个人感觉还真不值得写一篇文章来保存,所以也就没有跟随视频的更新而更新。

即使是自己产出的内容,就现在的情况来看也不是很有时间把视频落到文字上面。

不过之后可能就会有所变化了。为什么呢?因为我想变一变我的流程了——文字不是记录,而是草稿。

也就是说,在确定了视频主题后,先落实到文字,再做成视频。相对于现在临场发挥的录制法,这样兴许还会节省不少剪辑衔接的时间。

啊不说了,明天又该上班了。就祝这里的各位新年(公历)大吉吧。