@sjmcefc2 #63
CentOS 和 RHEL 不是更新缓慢的问题。RHEL 本来就是 3-5 年会出一个版本，你在他刚发布的时候用，当然什么都是新的。你等他过了 5 年再用，那当然什么都是旧的。RHEL 7 发布的时候 glibc 是 2.17 ，那么 7 这辈子都只能用 2.17 ，因为更新到新版本就会可能破坏这个平台上所有的软件兼容性。（有时候甚至有些 Bug 也不能修，因为有些程序会依赖一些 Bug 行为，随便修改行为也会导致其他程序出现问题。 ）

RHEL 的「稳定」并不是说「运行稳定」，而是说平台稳定，这个平台在生命周期中不会改变。Debian 也好 Ubuntu 也好，固定发行版都是这样的，一旦发布以后就不会再升级软件包了，而只会安装更新。

同理，一些专业的、大型的软件，也会固定在某个版本的发行版上进行开发。不少软件会要求说你必须使用某个发行版的某个版本来运行（比如 Tensorflow 要求 Ubuntu 16/18，我司开发的某个软件要求 Ubuntu 12.04 ，等等），因为他们只针对这个稳定平台进行开发和测试，你如果想要适配到别的发行版，那你就得自己做小白鼠吃螃蟹了。

@sjmcefc2 #53
我的意思是 Tensorflow 官方的 docker 镜像是基于 Ubuntu 制作的。

都重要，看一会儿，写一会儿。

@sjmcefc2 BSD 和 Linux 不完全兼容。很多为 Linux 开发的软件要放到 BSD 上运行可能需要移植。
Docker 在 BSD 上还处于实验性阶段，建议还是 Linux 为好。

话说官方的 Docker 镜像也是基于 Ubuntu 做的，所以你要么在 Docker 里用 Ubuntu，要么直接在母机上用。

除了 Ubuntu 的话那就是和他爹 Debian。Debian 如果再不喜欢的话就只能 Windows 10 了。

Debian 9 相当于 Ubuntu 17.04~17.10 ，正好落在 16.04 和 18.04 中间，所以应该也是能顺利跑的。

@luassuns Debian 跨版本升级还是很靠谱的。

支持你要用的软件的，就比不支持你要用的软件的，要好一点。

比如说他支持 Ubuntu 16.04+ （这个是 2016 年发行的，比 RHEL 7.x 新 2 年），那你装个 16.04 或者 18.04 就是很好的。

直接给 root 和给你一个账号然后提权到 root 没有任何区别，除了后者更麻烦。

你登录服务器是为了管理。管理必须用到 sudo。所以你每个命令前都加 sudo。
那么和直接开 root 并没有什么区别。

@Fule #7 reflog 不一定要 git 玩虚脱才会用到。如果你执行了一些命令进行测试，而稍后需要回滚，有可回收提交会方便很多。

PS: 我手头的 Git 图形界面会自动 gc，根本不需要手动做……

@sjmcefc2 #14
10 楼已经说过了，RHEL 7 是 2014 年发行的。别说 7.6，就是 7.998 ，那也是 2014 年发行的。
如果 Tensorflow 需要 glib 2.23 ，而 RHEL 7 没有 glibc 2.23+，那说明 Tensorflow 不支持 RHEL 7，你需要删掉你的系统，然后换一个支持的版本。

而且你有没有想过，你装上了 glibc 2.23 以后，整个系统里那么多依赖 glibc 2.17 的软件怎么办？

按照技能招人也不是你把自己限定在一种语言上的理由啊。

IP address 202.112.10.36
Reverse DNS (PTR record) gus.buptnet.edu.cn

北邮在 cn pool 里的节点吧。

所以每一跳到底多少时间？

说句题外话，行李箱上最好挂上名牌，里面写一份国内的地址，写一份国外的暂住地址，这样一方面不容易认错，一方面就算认错了别人也方便联系和送回。

新硬件的话先试着把内核升到 buster 的 4.19 看看？

@pypy 那邮件是从你们邮件服务器里发出来的吗？还是外面随便伪造的？

@pypy 怎么看出来用内部公共账号发的……

残響のテロル
PSYCHO-PASS 2
曇天に笑う
純情ロマンチカS1/S2/S3/OVA
進撃！巨人中学校
DIABOLIK LOVERS MORE,BLOOD
K RETURN OF KINGS / 劇場版
スタミュ S1/S2
ダイヤのA
金田一少年の事件簿 R
繰繰れ! コックリさん
不機嫌なモノノケ庵
ReLIFE
One Room S1/S2
Room Mate
舟を編む
フルメタル パニック S1/S2/S3/S4
ハイキュー!! S1/S2/S3/劇場版
猫がくれたまぁるいしあわせ公式
One Room 2
宇宙戦艦ティラミス S1/S2
文豪ストレイドッグス S2/S3
風が強く吹いている
曇天に笑う外伝
ダイヤのA S1/S2/act2

这不是我看过的动画列表，是近几年参与过或者进行中的字幕制作的列表。看过的比这个还要再多一些。

所以说这就是电影院不懂事了。

如果一张票卖 80，然后再要观众掏 10 块钱买眼镜，那肯定被观众喷死。
但是如果一张票卖 90，免费赠送一副眼镜，而自备眼镜的观众可以享受 10 元的价格优惠，那不仅不会被喷，而且还会被人赞赏这种环保行为。

@ihipop 那还不错。

如上所说，SSL 通信过程中，和「证书」有关的只是很小一部分，所以这个问题其实问的是 SSL 加密协商算法的效率而不是证书的效率。通常的流加密算法有 AES 3DES RC4 等等。其中 RC4 安全性有问题，但是速度很快。AES 靠谱但是速度稍慢，不过比较新的 CPU 都有硬件加密解密，所以也不会慢得离谱。

你问 ECC ？ ECC 根本就不是流加密算法啊，怎么比效率。

考虑到现在 RC4 已经被很多软件禁止使用了，效率比较高的 Cipher 是：
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

如果你 CDN 是自建的（即你可以控制 CDN 接受哪种 Cipher ），那么无加密是最好的，也即是：
ECDHE-ECDSA-NULL-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=None Mac=SHA1
ECDHE-RSA-NULL-SHA TLSv1 Kx=ECDH Au=RSA Enc=None Mac=SHA1
AECDH-NULL-SHA TLSv1 Kx=ECDH Au=None Enc=None Mac=SHA1