2019年9月

视频点此

霍金说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可以被系统监听到并响应吧…