本文记录了一个周日下午的日常。想来苹果这M1大概都出来半年了, M2/M1X都开始有传闻了,tensorflow应该支持得差不多了,实际情况似乎还是没有原生的官方二进制release。本文是记录的M1原生的编译,大概还有给Terminal开Rosetta 2 和 Miniforge两种方法本文不讨论.
M1支持的python版本大概是3.8.5+和python3.9.1+。
|
当前tensorflow官网给出最新的支持bazel版本是3.7.2,即使是最新的master分支也是锁死在3.99.0版本上,而bazel的release二进制从4.1开始才支持darwin-arm64的二进制release。
所以就打算直接用4.1版本的bazel了。对tensorflow的代码打一个patch。
|
bazel版本解决后按照官方的编译教程直接往下一路编译就正常了。似乎很简单是么?那我就不会写本文来记录了(^_^)
首先我们安装两个python依赖的时候大概是pip install numpy
会安装1.21.0。 但是目前tensorflow的master分支依赖的~=1.19.2
。 然后我们会注意到一个libclang的错误。
|
|
|
|
|
|
运行的结果
|
简直被Nvidia的显卡15ms/step暴击。Intel的260ms/step要慢。
|
结果
|
95ms/step还算可以吧。差不多是1060的35ms/step的三分之一。
本文记录chromium编译遇到的问题。 Windows上的Chrome浏览器一直都用着一个自己编译的版本。然而最近几个月的编译发现了Twitter的视频似乎没法播放,而Youtube的视频依然是正常的。
如上图所示。 搜索了一圈,尝试了重置浏览器(重新指定一个cache目录)和修改chrome://about似乎都没效果。
但是编译的时候有报一个错误’use_h254’编译选项未定义。那就变有什么编码器不支持了。然后搜了下确实现在默认不带h254的解码器了。但是用proprietary_codecs = true
就可以再次启用。
下面这个配置是我2015年写的一个自动化脚本,大概一直用到现在2021年,中间可能有几次优化,但是大体上都是2015年那会写的。
首先假设下面的目录树在某个目录,那么其上一级目录要有depot_tools
文件夹,然后把如下内容填入。按照如下笔记拖下源码。这个大概20~30分钟就好了。
|
|
|
|
|
|
|
|
|
chrome编译似乎给100GB内存,32独占物理核,编译依然是2小时左右,时间和我笔记本32GB-8750H时间差不多。不像firefox只要20分钟就能编译完成,似乎远远快于笔记本。
磁盘嘛,一个版本大概50GB,给足100GB笔记满足,如果像我上面脚本一样要编译x86和x64大概需要200GB-300GB的磁盘剩余空间。
本文记录proxmox使用过程中的一些基本笔记。
这个会影响到更新,默认装然就是enterprise的。
|
|
我这是软路由,系统盘是系统自带的一个16GB的mstata。用ventory装好系统后,根目录/
所在的分区只有3.5GB,偶尔apt upgrade
都会导致磁盘不足,于是有了本节的代码。
|
其实自己内心一直比较贪心。有一堆设想和计划。比如按自己喜好实现一门语言做到编译到各种平台,比如js、x86,arm等。鼓捣一个稳定可靠的分布式个人存储系统,带透明加密,跨洲T级数据可靠同步,多后端(磁盘,Ceph,OSS, onedrive,gdrive). 鼓捣一个编译系统,至少可以随意起arm、mipse、x86_64 linux、windows编译环境,最好还能和我的gitlab集成起来。这些闲下来散步时都是有所考虑,但是似乎一年多了,还没有任何进展。想起来疫情期间也似乎也没有任何这方面的考虑,当然出差北京还了猫就和bct分了。让我有更多的时间来考虑这些事情了。
仔细想想,我发现我经常会被一些最新的技术比如rust、go、Haskell耗去不少经历,然而也并没有深入下去。这样最后结果就好像其实什么都了解一点,而且花费了大把的时间。但是其实都没到足够使用的地步。大抵上我的一些知识都是这种结构的。这样带来好处是似乎没有我没听说过或者不能在非常短时间内基本掌握的常规知识,但是往深了就和大家一样了。
结论就是,要有所取舍。有所为,有所不为。
]]>美亚买了一个14T的硬盘,经历两周从德国邮寄收到了。拆出硬盘,准备换入群晖,发现硬盘分区已经没有了,最小的那个分区是一个4T的硬盘,而且是当初的第一个硬盘,上面有群晖的系统分区。
本文主要记录操作过程,总时间不长,白天在上班,大概花了大概11+3个小时完成从4T到14T无损迁移,并且被群晖系统识别为全部容量。
这个工具大概比较多,我用的Diskgenius,用的双盘位的硬盘盒, 直接 工具 -> 克隆磁盘 -> 源磁盘选4T那个盘,目标磁盘选14T的磁盘,复制所有扇区。
一看时间需要12个小时,我就睡觉去了,早上起来,刚好拷完,用了大概11个小时。
14T的磁盘插入群晖,可以正常开机。 似乎问题解决了,然而群晖只能识别成4T。 在群晖系统网页里面试了下,没有扩展按钮。
因为当初对这台群晖定位是灵活,都是用的basic btrfs建立的分区。群晖关机,拔下硬盘,用便携的硬盘盒插入PC,diskgenius只能识别出里面的一个EXT4分区,另外的几个分区似乎没法识别Linux Raid分区
无奈只能用Linux挂载了,虽然用虚拟机大概也可以。但是我这里刚好有一台物理机,所以就把硬盘盒弹出插入Ubuntu系统了。
|
先尝试了下面的命令。
|
第一条命令提示扩展raid到了3.6T,这显然不是我要的。
用fdisk -l 看了下
|
好家伙,分区只有3.6T,再怎么扩展肯定都是扩展不上去了。解决办法也是很简单,直接强行改分区大小好了。试了下fdisk,没找到改分区大小的命令。然后试了下gparted,这个图形界面的工具。可以修改分区前后的空闲空间大小,好像也没法改变分区自己的大小。(其实用diskgenius拷贝完毕,就想过改分区大小,diskgenius菜单是灰色的(我是付费高级版本))。 最后大小parted命令好像支持,也很简单。
|
用fdisk看了下
|
分区层面似乎解决了
|
为了安心用mount /dev/md3 /mnt
然后看了下,文件都还在。于是umount /mnt
,拔下硬盘。
拔下硬盘插入群晖,开机。一看还是4T,但是磁盘管理里面多了一个扩展按钮,点一下就变成了12.22T了 。至此问题完美解决,无损迁移4T到14T了。
一些碎片笔记,主要是Debian的网络相关。
Debian的升级不像Ubuntu那样有一个do-release-upgrade
基本思路是,改源然后upgrade就好。
|
到这里下载最新的镜像zip,然后解压得到img文件。
lsblk -p
umount /dev/sda1
用盘符而不是分区
sudo dd bs=4M if=2020-08-20-raspios-buster-armhf-full.img of=/dev/sdX conv=fsync
sudo eject /dev/sda
一个tips,wifi的国家代码会影响到wifi的可用频段,比如5G连不上。
country=AU
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="MyWiFiNetwork"
psk="aVeryStrongPassword"
key_mgmt=WPA-PSK
}
https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md
https://www.cnblogs.com/liuliu-word/p/9646060.html
https://blog.csdn.net/u010164190/article/details/68942070
因为进行了几次 rpi-update
进行了固件升级,导致的问题。wifi一会儿就自动断网了。
|
主要是看到 Power Management:off
就好了
https://wiki.archlinux.org/index.php/Ad-hoc_networking
https://www.raspberrypi.org/documentation/configuration/wireless/access-point-routed.md
https://github.com/simondlevy/RPiAdHocWiFi
|
booteeprom
https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md
]]>问题其实在于我这个博客是octopress的,刚开始用的时候魔改了一堆东西,所以迁移其实有成本的,而且有些问题可能就是无解了,或者代价非常之高。然而近来从cygwin到Ubuntu似乎都是ruby 2.x了,导致我用的octopress以来的ruby环境找不到。
无奈只得用多版本共存了。python和nodejs和ruby这几个都各自有不少多版本管理软件。
具体到ruby我用的rvm(用rbenv)应该也一样。
问题在于Ubuntu 18.04的gcc是7.5的,编译ruby-1.9.x一定是通不过的!
所以无论怎么install一定都是失败告终。
搜了下,大概得知ruby-1.9.x只能在gcc-4.8上编译通过。想自己动手编译gcc了吗?虽然很简单,但是这样不优雅,不够通用。
然后找到了如下的包
https://packages.ubuntu.com/bionic/gcc-4.8
那就简单了 apt update && apt install gcc-4.8
就好了么?
其实现在rvm install ruby-1.9.3
肯定还是失败了。解决办法也很简单。 先执行下如下命令就好了
|
以后只需要执行export CC=gcc-4.8; rvm use 1.9.3
就好了
最近需要紧急分析某个AI引擎框架,需要用ImageNet动态调试下。一番搜索后发现度盘和GDrive的链接。由于杜甫环境在国外的机器上,所以选择了从GDrive下载。(虽然同时起了个screen下载度盘,四天过去了,还在70%卡住着)
要下载的是这个
Title: ImageNet ILSVRC2012
Size: Train:138G+Val:6G
https://drive.google.com/drive/folders/1dU3PiW6RRQkxfQL9qAR16EhSbUcsofQ8
也就是如何在服务器上用命令行下载140GB的文件。
这个我们能比较容易找到好几个,最后我用的这个go写的客户端 gdrive
这是谷歌GCP的一个特色(去年公司出钱让考过一个professional cloud architect证书)。IAM权限管理,为特点某种资源分配特点某种权限的账户,这个账户可以随时随时编辑和审计。 专门为程序用的账户就是service_account,是密钥对,而不是密码之类的。其实就是一个json文件。
具体来说操作步骤如下:
可以参考 https://developers.google.com/identity/protocols/OAuth2ServiceAccount#creatinganaccount
~/.gdrive
下面可以改一个简单的名字,比如改成 ~/.gdrive/g.json
gdrive --service-account g.json about
如果能正常显示GDrive的空间大小那么直接下载就好了,如果报如下错误则继续
|
https://console.developers.google.com/apis/api/drive.googleapis.com/overview?project=[PROJECT_ID]
首先启用 GDrive API
然后创建凭据 Create Credentials
需要创建一个OAuth Client ID凭据
等待大概几分钟,我大概是10分钟内再此尝试步骤3就好了。
首先用刚刚生成service account的账户打开要下载的GDrive链接,然后在要下载的文件上右键,选择 “获取共享链接”。 会得到一个如下的链接 https://drive.google.com/file/d/xxx/view?usp=sharing
那么下载命令就是如下了
|
速度大概可以稳定到10MB/s到30MB/s的样子,很快就下完了。
从上面的流程可以看出,我们不需要把这种超大的文件储存到自己的空间然后下载,其次谷歌知道你在下载。所以谷歌也可以控制你滥用。这个其实是有额度的,具体看谷歌API limit方面的说明,理论上次数和流量应该都是有限额的,假如商用的也是有付费服务的。
时间都去哪里呢?我是知道了,大概也就归于网络世界虚无了吧。
就这样吧,分享几张奶牛的图
]]>因为里面跑的其他几个服务都还正常,如果不是因为习惯登录进服务器进行apt update && apt -y dist-upgrade
还不会发现这个问题。
环境详情: 国外的几家ovz都没有这个现象,估计还和母鸡有关。遇到问题的是Ubuntu 16.04,其openssh-server版本如下
|
刚某个服务商支持串口,所以研究了如何绕过这个问题。通过串口登录进去,查看,ssh启动失败的日志如下,以及尝试手动启动ssh服务。
|
其中最关键的是Missing privilege separation directory: /var/run/sshd
,发现这个目录确实不存在,创建这个目录,然后systemctl start ssh
居然就成功了! 重启,sshd依然没有启动! 看了下这个目录又没有了!
由于没有心情研究具体出问题的是在openssh-server这个包上,还是其他库比如libc上(升级时提示libc版本号不足)。接下来就是如何把这个过程自动化。 我的解决办法是在/etc/rc.local
加上如下内容:
|
然后就好了。算了,能用就好!
]]>rc.local
dnsmasq似乎常常用于简单用途的dns缓存,比如防止解析泄漏、作为dhcp服务器等。可以跑在服务器上,但也许更多的情况是跑在手机上或者路由器上。本文记录几个使用过程中遇到的问题。
之前我一般是修改的/etc/dnsmasq.conf
,但其实更好的是,在/etc/dnsmasq.d/
新建按功能命名的conf文件。
|
一定要是这个顺序,交换下前三行顺序,然后就怎么都起不来dnsmasq.service了。
一般我都是改动了一下的。按照如下提示修改。
|
rc.local
一般情况下,似乎只在openwrt之类的路由器上见得比较多,如果有systemd,写个systemd unit最好不过。写个/etc/init.d/
脚本也行。
我的/etc/rc.loal
内容如下
|
然而每次reboot重启之后,dnsmasq都没有启动,提示的是dnsmasq.service: Job dnsmasq.service/start failed with result 'dependency'.
。而登录上去手动执行systemctl start dnsmasq
却可以正常启动。用journalctl -xe
查看日志,找到如下:
|
机子上其实还装了docker和wireguard,可能是执行rc.local的时候,正好有其他的正在执行iptables。所以解决办法其实也挺简单将/etc/rc.loal
最前面加一个sleep 5
,然后就好了,反复重启都暂时没遇到dnsmasq起不来的情况了。 像这种用sleep
延迟执行时间的做法显然不完美,正确的做法应该是写个systemd,然后写好依赖,然而现在能用,也就此作罢。
只需要注意systemd-resolved侦听的是127.0.0.53:53就好了。 参考如下命令笔记
|
大都启动有问题,但是去掉 interface=tap_soft
与 bind-interfaces
貌似可以一用。
这几天发现树莓派上的owncloud-client登录不上了,退出登录后再登录,在输入完密码账户后,最后那一步总是提示”Error transferring …/remote.php/webdav/ server replied: Forbidden”。
如下图:
一个月前应该都是用过的,而且win和手机的客户端端每天都在用,所以排除服务器故障。因为采用最小权限原则,树莓派上用的是一个单独账户,期初还怀疑账户权限问题,然而web登录正常,所以记起大约半个月前,owncloud和nextcloud同时更新过版本号。那大概是兼容性问题!因为树莓派的包大抵都很老,而且是armhf,可能是版本过低的缘故。
目前我的cross-build环境还没搭起来,所以只能找一下原因了。
先看一下web界面左下角设置里面提供的WebDAV地址,https://1.1.1.1/remote.php/dav/files/admin/
,咦,好像哪里不对! remote.php
后面接的路径不对!
于是乎先找changelog,找了owncloud官方 server changelog 和 client changelog,搜webdav,果然看到Switch to new ownCloud server WebDAV endpoint
和Switch Webdav URL in field in navigation panel to the new endpoint
的字样。
然后在github的owncloud/client里面release下载了2.2.4和2.5.0的源码,随便搜了一下。
|
说明确实2.2.4的时候没有支持新的URL。不过对服务端源码10.0.9和10.0.10代码分析时没有找到问题关键所在,没有确定是哪一版本的服务端开始不支持remote.php/webdav/的。
找了下,找到一个如何编译树莓派的owncloud-client
为啥用的owncloud?因为它兼容性好,比如在IE8上面可以正常登录,不乱码。 其实Nextcloud和Seafile我都是一起跑着的。感觉上速度最快的是seafile。而Nextcloud特性比较多,比如rss源,然后手机上可以用客户端当做新闻阅读器,还有Nextcloud Talk等,因为我把能启用的插件都启用了,所以感觉上web ui速度比较慢,一般也就只当做下载器/新闻阅读器用了,存储都放到了简单稳定的owncloud了。而且owncloud也支持Nextcloud的office,均能在线编辑office文档,所以作为存储和办公来说,owncloud刚刚好。Nextcloud适合娱乐用。Seafile主要是账户设备数量限制,所以我基本上啥都不想存进去。
]]>本文主要是把平时记录的Notes中,参考次数比较多的笔记摘录出来,供不时之需。
其实是一部分实际问题,乘着写文章整理一下。下面这些问题都是单条短命令,去掉问题中可能包含的字符后,应该不超过20个非空白字符,大都是10个内字符。
apt list vim
或者 dpkg -l vim
dpkg -L vim
/bin/vim
这个文件属于哪个包? dpkg -S /bin/vim
apt-cache depends vim
apt-cache rdepends vim
dpkg --get-selections | grep linux
apt-cache search vim
apt-get source nginx && apt-get build-dep nginx
(这里要求配置了deb-src源,另外debian packaging话题较大,此略过)dpkg-reconfigure tzdata
对于浏览器或者命令行本身支持socks5的这里不谈。命令行种类繁多,用过一段时间proxychain,然而有些情况下似乎不太好用。 其实比较希望linux命令里面实现按域名(可自定义)类似PAC的方式实现外网访问。
首先安装privoxy(或者功能差一些的polipo) apt-get install privoxy
,然后配置一下需要处理的域名列表。
我用的是 gfwlist2privoxy , 这个脚本貌似有点问题,第一行有个多余的输出,直接删掉就好,然后把github的域名加到第一行,强制github.com走外网。具体参考其readme就好了。
|
接着跑一个或者多个ss-local、v2ray、kcptun等socks5客户端,推荐全部用systemd管理,比较方便,此处略过具体安装步骤。可以同时起来多个,方便切换。 关于配置,我一般如下:systemctl edit shadowsocks-libev-local@local
,敲一个回车留一个空白文件然后保存。接着编辑/etc/shadowsocks-libev/local.json
加上适当的配置,然后执行systemctl enable shadowsocks-libev-local@local
和 systemctl start shadowsocks-libev-local@local
就好了。 (说明:其中shadowsocks-libev-local@%I
的@后面接着的字符对应于/etc/shadowsocks-libev/%I.json
,所以你可以方便同时起来任意多个客户端。)
一个样例local.json
|
好了现在所做的工作还只是在把1080的socks5转换成了http/https的8118而已。接下来就是让命令行程序使用它。这个问题比较推荐参考ArchWiki/Proxy settings。
把上面Archlinux的wiki里面的proxy_on proxy_off两个函数拷贝到~/.bashrc
里面。
|
然后source ~/.bashrc
,接下来执行proxy_on
,那么就开启了。 但是现在执行sudo
提权命令时却依然不会走外网。解决办法是sudo visudo
,在里面加上Defaults env_keep += "http_proxy https_proxy ftp_proxy"
。这句的作用是提权时让这三个环境变量维持不变。
测试一下
|
有时会特地希望某个没有被和谐的域名走外网,那么只要编辑 /etc/privoxy/gfwlist.action
加进去,然后重启privoxy就好了。
现在就可以安心地拖chromium或者Android的源码了。不需要时也可以执行proxy_off
关掉。
至于udp2raw和frp等,等下次再补充。
这个存储在/etc/network/interfaces
,参考Debian/wiki/NetworkConfiguration和Ubuntu/wiki。DebianWiki其中包含几个高级一些的配置:桥接(Bridging把多个网卡聚合到同一个子网)、VLAN(dot1q, 802.1q, trunk,)、单网卡多IP配置等。而Ubuntu文档则有关于Ubuntu-18.04采用的systemd-resolved的说明。
今天更新了下博客主题,记录下内容。
前一篇文章有几张图片,看起来有点模糊,所以考虑加个fancybox,顺便也把置顶解决了下。
用的是纯前端的解决方案,没有用jekyll插件的方式。插件方式可以参考 给博客写了个 Fancybox 的插件。 因为过多使用一些没有必要的Liquid标记,会对markdown文章造成污染,不利于迁移操作。
我主要是参考的 Octopress Customizations 和 在Octopress中添加图片放大,不过主要是前者,因为我的图片都没有用img标记。
具体来说,用如下方式表示图片
|
后面那个{: .center .fancybox}
是kramdown的class标记。 接下来下载fancybox,把source目录里面的内容解压到source/javascripts/fancybox
。然后只要改下模板,head区域导入fancybox的css和js以及footer区域执行触发fancybox。
|
与
|
因为octopress背靠的jekyll这座大山,背后社区是比较庞大的。静态博客程序的star排行榜上,Jekyll是排第一的,遇到问题比较容易搜索到解决办法。
所以我用的是 Jekyll: Making Posts Sticky Redux 中的第一种方法。也就是修改source/index.html
和source/_includes/article.html
|
在source/_includes/article.html
中适当地方加上如下内容就好了。
|
今天无意中看见个CN2线路,2核+4GB+4T的VPS,打了下折之后年付18美元。这么便宜,我都不敢把服务商写出来了。当然这是OpenVZ的,目前看来还好,将来不知道会被玩坏成什么样子。
开源的自建git项目托管服务,貌似有模仿github用ruby写的gitlab,用scala基于JVM的GitBucket,以及国人用golang开发的gogs/gitea等。功能最完善的当然是gitlab了。 gogs可以跑在路由器、树莓派等低配置硬件上,听闻国内有小团队直接用树莓派挂块硬盘跑gogs作为公司的代码仓库。至于GitBucket,没试过,猜想应该具有Java一贯的容易部署高内存消耗的特性吧。
之前想装gitlab,都被官方文档的推荐内存要求吓退,最终都换成了gitea/gogs。虽然kvm可以通过swap加大内存绕过,但是好像比较卡,所以都没怎么用过。
测试了下搭建私有gitlab带Web-IDE的持续集成环境。
目前能做到在gitlab网页上编辑一下文件或者本地编辑后push一下,会自动触发gitlab-runner(一个docker虚拟机环境),进行自动的编译和测试工作。如果编译与测试均成功通过,则进行部署。这样简化软件开发流程。
如下四张图
我的惯例是如下,首先禁掉密码登录(nano /etc/ssh/sshd_config
),然后更新(apt-get update && apt-get -y upgrade
),重启(reboot
)
这里只随手打一下习惯性手指条件反射记得的包
|
按照我一贯的习惯,能用包管理,尽量用包管理,docker次之,最次脚本安装。直接按照官方文档就好。
|
之前有玩过bitnami的虚拟机版本gitlab,那个是GitLab CE。然而GitLab官方在这里说GitLab Enterprise Edition版本具有社区版本(MIT Expat license)的全部功能,而且能随时使用商业版以及试用过期后回退到社区版。故而直接安装企业版。
|
先加入GitLab官方的源,并导入密钥。
现在去设置一下dns,把域名指向过来。然后就可以通过包管理来安装了
|
小插曲:安装过程中会自动设置letsencrypt证书,我预想的是只是配置而已,然而当我看到letsencrpt字样的dpkg error时,就发现了这安装程序原来集成了自动配置证书功能。
打开网页就是一个密码输入界面,这里输入的是GitLab的root用户的密码。然后注册了一个普通用户,发现没有任何验证,赶紧用root用户管理员关掉任意用户注册功能。
我并没有配置太多,只是换了下favicon与logo,然后用普通权限用户的ssh实验了下private项目的pull与push。 具体过程和github与Gitbucket没啥区别,这里不赘述。 当然修改gitlab.rb
之后gitlab-ctl reconfigure
这个应该也是要养成习惯了。
默认是没有开启Pages服务的。由于有点想当做博客/维基用的想法,所以研究了下。也挺简单,参考官方文档,一小时搞定。
首先要泛解析另外一个域名,出于防范XSS攻击考虑,官方不推荐用gitlab服务的主域名。而且gitlab的安装程序目前似乎还不能自动配置泛解析letsencrypt证书。
Let’s Encrypt支持泛解析测试的时候就看到过尝鲜用户的报告。印象中acme.sh是支持得最好的。我用的是如下的指令
|
然后修改/etc/gitlab/gitlab.rb
找到gitlab pages相关的地方 最终如下
|
虽然有openvz官方的这篇说明openvz是可以支持docker的,然而我的这个好像不支持,下单时我应该选3.x kernel的。 不过还好gitlab-runner好像就不推荐和gitlab跑在同一个机器上。
在另外一台也是极端便宜的小鸡上装了个gitlab-runner
参考docker官方文档
|
参考官方文档
|
配置相对来说比较方便,Runner executor选docker,然后镜像选择ruby:2.3就好了
|
另外gitlab-runner配置在/etc/gitlab-runner/config.toml
|
应该在runner上面勾选Run untagged jobs [] Indicates whether this runner can pick jobs without tags
看了下付款记录,11点付款,下午2点多开始想搭gitlab,到现在写完本文下午6点钟。 整体上比较简单,只要照着官方文档复制粘贴命令就好了。
今天好像Debian系列的libc都升级了,于是惯例升级下系统。然而gitlab这次遇到了点儿问题记录下。
|
如果继续运行 apt-get update && apt-get -y dist-upgrade
则是类似如下的错误
|
期初我以为是内存的原因,于是/opt/gitlab/bin/gitlab-ctl status
然后 /opt/gitlab/bin/gitlab-ctl stop
以及/opt/gitlab/bin/gitlab-ctl start postgresql
和/opt/gitlab/bin/gitlab-ctl start postgres-exporter
。这样内存占用减小到了206M/4G,而且开了另外一个终端实时监控内存使用情况,发现运行dpkg -i /var/cache/apt/archives/gitlab-ee_11.3.1-ee.0_amd64.deb
过程中,内存从来就没超过1G。于是基本否定内存不足的情况了。
运行如下三条命令即可解决
|
老版本依然在运行中,而且没有卸载。所以新版本无法覆盖。
]]>一段时间没有更新博客了,记录倒是一直都有的,养成了写操作日志的习惯,要是发出来得有100多篇,不过可能包含不少敏感内容,而且操作日志也算不上什么创造性的内容,就此作罢。
嗯,这个博客主题确实有点儿过时了。
比如hexo或者hugo,采用的人就很多。做个hexo主题似乎就可轻松收割上千stars (https://github.com/yscoder/hexo-theme-indigo ),乃至成功的到了上万stars (https://github.com/iissnan/hexo-theme-next)。
先尝试了下hexo NexT主题,用的来自 https://github.com/theme-next/hexo-theme-next 最新版,把octopress里面的_posts目录拷贝过去,运行hexo s
,一切正常。 跑起来似乎还不错,主题也是全新的。
然而,很快我就发现一些痛点并没有被解决,而且一些octopress的特性被扔掉了。
|
据我观察,似乎很多hexo博主文章url就是汉字,另外一部分手工翻译的英文。
有点儿想把sublime汉化插件那篇文章置顶下,折腾了一圈,发现没有好的解决办法,找到了两三个workaround(1 2),但是看评论似乎都有bug,而且随着hexo官方升级以及NexT主题升级,随时会broken,这就是我一贯不喜欢nodejs项目的原因,包依赖非常脆弱。
同样想隐藏部分文章,而且这个需求可以继续细化。部分只是不想在首页上显示,有的是想作为草稿撤回。
Octopress用了有这么几年了,改动过很多地方,添加了一些私有扩展,暂时hexo没有找到想要的功能。
有Algolia Search,另外还可以用纯js做的前端本地搜索。
似乎hexo从开始就考虑了多语言支持,这比octopress的那个插件要好很多。
毕竟前端语言写的
留空
暂时结论,自己改Octopress/Jekyll的主题,虽然生成时候相对nodejs、golang要慢一点,但是都是静态博客,敲下回车就去泡咖啡了,谁在乎生成的快慢!
]]>偶尔我们会想获取汉字的编码,然而似乎网上随手一搜,在线转换工具倒是有不少只是好像都不太能满足真实需求。
也许你会想到notepad++按照编码保存,然后用二进制打开。当然这在Windows下不失为不错的办法。
鉴于UTF-8推荐的越来越多,我就来列举下它对于中文来说的缺点。
顺便也说说对于汉字,UTF-8其实并不适合保存。虽然因为现在互联网应用交换的绝大部分都是html/css/js的原因,utf-8格式大行其道。但是对于中国的常规应用来说,其实不需要用UTF-8表示。
简单点说:对于一个以英语为主,偶尔会需要显示一两个汉字,那么utf-8优势巨大。对于基本上是汉字,只需要偶尔显示一两个英文缩写的应用。GBK或者UTF-16优势巨大。
原因在于汉字、日语都被UTF-8都被编码到了三字节,然而其中的有效位只有两字节,剩下一字节是用来做标志位的。也就是每个汉字要多浪费一个字节。而且UTF-8是变长编码,从1到4都会出现,对于字符串函数实际上很不方便。当然对于库函数丰富的今天这不算大问题,只是进行了一次内码转换而已。 而且3字节的汉字,中间夹杂着1字节的ASCII字符,这种编码在内存中处理,实际上非常麻烦的,不停要做移位操作,连简单的字符个数都是O(n)的。
好了批判完了,写点有用的。
我的方法是用Python,简单轻量级。
|
这是是给 ALT + 数字
这种输入法用的。 需要注意的是,这里要用大端。
|
中文Windows下面按住Alt键,快速输入52946,就会出现汉字我
.
我们来测试下本文的markdown,上面的文本。
|
0xfffe
是BOM,可以发现UTF-8对常见汉字编码确实要多一个字节的。
|
编码 | 生效日期 | 备注 | 编码范围 |
---|---|---|---|
GB2312 | 1981.5.1 | GB2312编码共收录汉字6763个,其中一级汉字3755个,二级汉字3008个。同时,GB2312编码收录了包括拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母在内的682个全角字符。 | A1A1-FEFE(41377-65278)其中汉字编码范围:B0A1-F7FE(45217-63486)。 |
GBK | 1995.12.15 | GBK编码,是对GB2312编码的扩展,因此完全兼容GB2312-80标准。GBK编码依然采用双字节编码方案,其编码范围:8140-FEFE,剔除xx7F码位,共23940个码位。共收录汉字和图形符号21886个,其中汉字(包括部首和构件)21003个,图形符号883个。 | 8140-FEFE (33088-65278) |
GB18030-2000 | 2000.3.17 | 是对GBK编码的扩充,覆盖中文、日文、朝鲜语和中国少数民族文字,其中收录27484个汉字。GB18030字符集采用单字节、双字节和四字节三种方式对字符编码。兼容GBK和GB2312字符集。 | 采用单字节、双字节、四字节分段编码方案,具体码位见特性。GB18030向下兼容ASCII码和GBK编码。 |
GB18030-2005 | . | 最主要的变化是增加了CJK统一汉字扩充B。它还去掉了单字节编码的欧元符号0x80)。GB18030有1611668个码位,在GB18030-2005中定义了76556个字符。 | . |
GBK 的代码页是936,GBK18030的代码页是54936.
Windows记事本的ANSI编码
ANSI (American National Standards Institute) 美国国家标准学会的缩写。 在简体中文Windows操作系统中,ANSI 编码代表 GBK 编码;在繁体中文操作系统中,ANSI编码代表Big5编码;在日文Windows操作系统中,ANSI 编码代表 Shift_JIS 编码。
关于Unicode与UTF-8 UTF-16 UCS-2的关系
Unicode(统一码、万国码、单一码、标准万国码)编码就是为表达任意语言的任意字符而设计。特点: 一个字符代表一个code,不存在二义性,而且这套标准也会随着需求不断的拓展。由非盈利机构 The Unicode Consortium 负责,官网为 http://www.unicode.org/
Unicode是一个标准,只规定了某个字符应该对应哪一个code,但是并没有规定这个字符应该用即为字节来存储。规定用几个字节存储字符的是Unicode的不同实现,譬如UTF-8,UTF-16, UTF-32等。
所以 UTF-8 UTF-16 的编码范围都是全部的Unicode字符集的。
UTF-8是采用变长的编码方式,为1~6个字节,但通常我们只把它看作单字节或三字节的实现,因为其它情况实在少见。。
Unicode编码中,最常用的字符其实是0-65535,因此针对这点产生了UTF-16方案。 UTF-16将0–65535范围内的字符编码成2个字节,超过这个的用4个字节编码。(因此基本可以认为是双字节的) UTF-16是完全对应于UCS-2的,即把UCS-2规定的代码点通过Big Endian或Little Endian方式直接保存下来。所以UTF-16采用2个字节来存储Unicode。UTF-16也可以表示UCS-4的部分字符,所以UTF-16也采用4个字节来存储Unicode。 UTF16编码是Unicode最直接的实现方式,通常我们在windows上新建文本文件后保存为Unicode编码,其实就是保存为UTF16编码。
其他汉字编码BIG5 Shift-JIS
BIG5编码又称大五码,是繁体中文字符集编码标准,共收录13060个中文字,其中有二字为重复编码。BIG5重复地收录了两个相同的字:“兀、兀”(A461及C94A)、“嗀、嗀”(DCD1及DDFC)。编码范围8140-FEFE(33088-65278) 其中汉字编码范围:A440-F9DC(42048-63964) BIG5采用双字节编码,使用两个字节来表示一个字符。高位字节使用了0x81-0xFE,低位字节使用了0x40-0x7E,及0xA1-0xFE
Shift-Jis比较特殊,不连续,需要校验合法性,而且有特殊的转换公式与技巧,有时会在代码中看到。
ASCII字符 (0x20-0x7E),但“\”被“¥”取代 ASCII控制字符(0x00-0x1F、0x7F) JIS X 0201标准内的半角标点及片假名(0xA1-0xDF) 在部分操作系统中,0xA0用来放置“不换行空格”。
以下字符在Shift_JIS使用两个字节来表示。
“第一位字节”使用0x81-0x9F、0xE0-0xEF(共47个) “第二位字节”使用0x40-0x7E、0x80-0xFC(共188个)
“第一位字节”使用0xF0-0xFC(共13个) “第二位字节”使用0x40-0x7E、0x80-0xFC(共188个)
在Shift_JIS编码表中,并未使用0xFD、0xFE及0xFF。
在微软及IBM的日语电脑系统中,在0xFA、0xFB及0xFC的两字节区域,加入了388个JIS X 0208没有收录的符号和汉字。
]]>clang是我自己从源码编译3.8.0版本。执行clang -v -E -x c++ -
得如下内容:
|
去Windows Kits目录里面一看,发现C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\shared这个目录才是对的。
蹭蹭地跑去llvm社区maillist求助,得到修改clang/lib/Driver/MSVCToolChain.cpp
的提示,看来下,要做似乎挺简单。然而我习惯每天更新llvm源码,哪天心情不好就会重新编译,所以改源码似乎不是上策。于是想到了linux每天都做的事情,ln -s
啊!
新建快捷方式,复制进去。不行依然找不到。
然后依稀记得以前见过NTFS的硬链接和软连接。于是问题迎刃而解了。具体方法参考这里。
下载Junction,然后junction shared 10.0.10240.0\shared
即可,对另外五个目录同样方法。
再次测试
|
然后ycmd就可以在Windows上面补全Win10 Kits的头文件了。
补充:
刚刚发现实际上mklink
可以干同样的事情。
Windows里面“连接”分四种:硬链接(Hard link)、联接(针对目录,Directory Junction)、符号连接(symbolic link)、快捷方式(Shortcut).前三种对应于mklink的三种参数 /h
/j
/d
。而且mklink是vista以后系统自带的。这样就方便很多了。对于本文的问题用 mklink /j
即可。
而广为人知的快捷方式,实际上是*.lnk文件,它内容就是网址或者文件地址(还可以包括快捷方式图标等文本信息),有大小的一个文本文件,在Windows的文件API上面做了透明处理。似乎没有办法通过普通文本编辑器打开lnk文件而不跳转到它连接的文件。这就是可以把快捷方式到处拷贝剪切和改名。
而硬链接、联接和符号连接属于NTFS文件系统底层一些的级别的。
而通过右键属性观察,符号连接和快捷方式几乎一样。区别就是快捷方式可以拷贝到Fat32的优盘,而符号链接则只能存在NTFS文件系统上。
]]>问题就是:①移动磁盘上建立一个vmware虚拟机,然后用win10的iso镜像安装,安装完成后,如果重启,则可以正常重启,但是一旦关机,则再次开机一直都是Bug Check 0xC000021A,然后进行dump,为此我特地用 "windbg.exe" -b -k com:pipe,port=\\.\pipe\com_1,baud=115200,reconnect -y
在线内核调试了下,但是水平所限(等到哪天有空了再来看看究竟),没有找出问题的究竟,但是错误的字面倒是说shell32.dll校验错误。而我用Diskgenius把它拷贝出来,校验是正常的。
②BT5-R3,CentOS7,RHEL7这三个我使用多年的vmdk,最近因为磁盘空间紧张,转移到了3T的移动硬盘上面(这个移动磁盘拷贝文件一般稳定70+MB/s,有些时候稳定在100MB/s,这里的数值是实际拷贝文件时Windows显示的。) 然而把这三个虚拟机开机一次,然后update一下,如果升级的有kernel,也就是boot分区内容有变化的话,下次就没法开机了。具体到CentOS和RHEL7就是如下
|
此问题什么时候开始的已经不可考了,但是WinXP/Win7/Win8应该是不存在这个问题的,总之最近的一些新系统关机后就再也无法开机。我注意到是磁盘的问题,而且是磁盘问题则是最近安装在移动硬盘上装win10。我尝试了检查磁盘,检查iso的hash,最终无意中发现在本地磁盘上安装就可以避免。
这个问题我可以完全排除磁盘坏道,或者NTFS元信息错误。均做过检测,正常且优良。
Win10的解决办法目前就是在本地磁盘安装,然后移动到移动硬盘上去。而CentOS7/RHEL7因为是xfs系统,所以存在一个特别的解决办法。开机后如果看到 Generating "/run/initramfs/rdsosreport.exe"
这种方式的错误,而且最后停在:/#
的root shell上面,那么可以直接执行 xfs_repair -L /dev/mapper/centos-root
即可(RHEL7是rhel-root)正常开机启动。而如果是EFIs错误,则可以用iso光盘Rescue功能,进入之后选择 Skip
,然后再shell里面执行上面xfs_repair,则就可以救活移动硬盘上面的CentOS7/RHEL7系统。
这里只是大胆“瞎说”,目前没有进行验证。
Win10的启动分区和CentOS7/RHEL7的xfs里面的boot部分,有非常底层的代码和硬件编号还是什么相关联,而vmdk动态修改的过程中可能会发生重新分配物理地址,中间引起了什么混乱。
另外一个猜测就是我只在最近才发现,而3T最近快装满了,这是不是说明vmdk文件在物理磁盘上碎片的时候才会出现这个问题?
Win10物理机上面用Vmware Workstation 12.
移动硬盘用Diskgenius检测坏道数量0,有600个良,其余均是优。
移动硬盘用chkdsk查不出问题。
CentOS7只要一操作内核(删除/升级),必定是可以直接重启,但关机后开机必定CRC mismatch.
Win10在本地磁盘安装好后,拷贝到移动硬盘,再在里面安装各种软件,开关机均正常。
Win10直接在移动硬盘新建虚拟机不下5次,均是可以重启,关机后开机必定0xC000021A
这里有一个类似情况,不过是他不是移动硬盘,而是Windows Server2012的存储池。存储池必定CRC mismatch,本地磁盘正常。
最近发现好像问题在于SCSI磁盘的问题上,也不知道问题出在哪个地方。避免在移动硬盘上使用SCSI磁盘即可避免问题。
参考这里。
]]>在VS编译的64位gvim支持了Python2/3,ruby,perl,tcl,lua之后(参考在Visual Studio编译gvim和ycmd),发现配置里面还有一个叫做MzScheme,而且是在Make_mvc.mak里面,就是说原生是支持VS编译的。那么开启吧。
先来看效果吧!
这个相对上面几种语言来说,应该是最难编译了。因为mzscheme已经变成Racket了,然而4xx版本以前的只能在原网站下载,新版本的5xx与6xx似乎就完全改成新名字Racket了,已经见不到mzscheme的字样。
按照我的惯性,首先当然就是下载64位的安装程序racket-6.1.1-x86_64-win32.exe(写本文的时候已经升级到了6.2.2了),但是几处硬编码patch后,是链接失败。于是我怀疑库的问题,于是我便源码手动编译,然而问题依旧。实际问题是vim最新的源码似乎并没有完全迁移到支持Racket 6xx,反正这里有好几个tricks,我是直接读源码才搞明白怎么回事的。
首先第一个问题是Racket/MzScheme版本是多少6.1.1?611?都是错的。我们来看看PYTHON_VER=27
PYTHON3_VER=34
PERL_VER=520
TCL_VER=86
TCL_VER_LONG=8.6
RUBY_VER=22 RUBY_VER_LONG=2.2.2
LUA_VER=53
,似乎直接就会写MZSCHEME_VER=611
而通过读vim/src/Make_mvs.mak
,很快弄明白了,它就是用来链接库的后缀的,比如Python27.lib,而这个27就被写成了PYTHON_VER=27
,以达到代码的通用性。然而我们去看看Racket\lib\msvc
,简直“不堪入目”。
6.1.1的版本是如下四个文件
libracket3m_9xtjc8.exp
libracket3m_9xtjc8.lib
mzdyn3m.exp
mzdyn3m.obj
当然我立即意识到了,MZSCHEME_VER=3m_9xtjc8
,然而问题远没有这么简单。
它有一个依赖
|
这句真的是mzscheme的,然而一番搜索,发现现在的应该是raco ctool --c-mods mzscheme_base.c ++lib scheme/base
,而实际上在6.1.1上面则应该是raco ctool --c-mods mzscheme_base.c ++lib racket/base
src/if_mzsch.c这个地方总是报链接错误。
于是我来探寻一番,启动VS2013 x64 Native Tools Command Prompt,我们来到Racket\lib\msvc里面。执行dumpbin.exe -headers libracket3m_9xtjc8.lib | findstr /c:" Symbol name :">libs.txt
,然后打开搜索scheme_register_tls_space,确实找不到!
然后我们来到了Racket/doc/inside/im_memoryalloc.html?q=scheme_register_tls_space#%28cpp._scheme_register_tls_space%29这里,Only available on 32-bit Windows,也就是说64位不能用。然而不让用有啥替代呢?上下翻了下,没有说明。于是不管怎么样先pass过编译再说吧,于是注释掉了
|
很顺利编译通过了。然而启动gvim执行:mz (+ 1 1)
却是程序无响应退出。启动Windbg_x64,先Attach上去,按F5跑起来,然后再次执行:mz (+ 1 1)
,于是我发现Windbg_x64也是支持源码级别的调试的了!真是强大。
因为3m版本的对C语言支持没有CGC版本的友好,于是手动编译Racket。直接官网下载min版本的源码。然后二话不说执行racket-6.2\src\worksp\build.bat
,直接就编译好了最新版本的Racket,对我来说比安装exe真的要容易啊,因为它是pdb调试文件的啊!然后执行raco install
安装完整的racket库。
实际上我成功的链接是用CGC版本的,也就是MZSCHEME_VER=xxxxxxx DYNAMIC_MZSCHEME=no
为编译参数,同时对源码打如下补丁。其中libintl.dll
改成intl.dll
是因为我自己用Visual Studio编译64位的gettext的时候发现现在已经官网名字确实已经是intl.dll
,而且这个在vim官网的下载页面有明说,它给出方案是把intl.dll
改成libintl.dll
,而我则是改vim的源码。因为我不需要像vim官网一样顾忌老系统的支持。
|
本文内容已经于7月10日被Bram Moolenaar在7.4.772合并到了主分支了。
]]>