@FindBoyFriend 不建议生产用。

@kmdd33 我又试过你用的 remi-php71 仓库了，是这样的：

https://rpms.remirepo.net/wizard/

# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
# yum install yum-utils
# yum-config-manager --enable remi-php71
# yum update
# yum install php

Installed:
php.x86_64 0:7.1.16-1.el7.remi

# php --modules
[PHP Modules]
（略）
zlib

[Zend Modules]

@kmdd33 我用的官方推荐的 SCLo 仓库。我没有指定过任何目录，是 SCLo 打包者指定的。

我是坚定不移地反对裸编译的。最少最少，用来生产的环境是必须要由包管理负责的。直接 make 然后 install，会把系统里的依赖搞得一团糟，很快系统运行环境就会变得无法控制了。

我看你激活了 remi 仓库，那你可以去 remi 仓库的软件列表里找 PHP 来安装，何必要自己编译呢。我激活的是 centos-sclo-rh 和 centos-sclo-sclo，你可以根据自己的情况去寻找对应的方法。

你可以试着 --with-zlib 编译。

我没用过 CentOS 7，前面去买了一台服务器，装上了，花了 10 分钟从软件源里安装了 PHP 7.1，成功激活 zlib。

# yum install centos-release-scl

# yum install rh-php71-php

# /opt/rh/rh-php71/root/usr/bin/php -i | grep zlib

Registered PHP Streams => https, ftps, compress.zlib, php, file, glob, data, http, ftp, compress.bzip2, phar, zip
Registered Stream Filters => zlib.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, bzip2.*, convert.iconv.*
zlib
Stream Wrapper => compress.zlib://
Stream Filter => zlib.inflate, zlib.deflate
zlib.output_compression => Off => Off
zlib.output_compression_level => -1 => -1
zlib.output_handler => no value => no value

我觉得这应该是最简单的方式了。

ZLib Version 1.2.7
我觉得还行？

你 PHP 是用的系统自带的软件包安装的吗？

CentOS 7 里的包已经默认编译进 zlib 了。

https://centos.pkgs.org/7/centos-updates-x86_64/php-5.4.16-43.el7_4.1.x86_64.rpm.html

Requires
...
libz.so.1()(64bit)

所以你装好 PHP 以后，zlib 就已经在工作了。

你可以说说看为什么你认为没有 zlib 支持。

> 同容量的移动硬盘比机械硬盘的价格还便宜，是不是可以用移动硬盘替代？
可以。同容量的移动硬盘比机械硬盘保修短，保修的差别就是价格的差别，你可以自己决定。移动硬盘里塞的就是普通的机械硬盘。

> 单盘应该选择多大的容量？
3T 和 4T 技术成熟，比较适合大规模部署。单 TB 价格也可以接受。

> 应该选择哪个品牌的什么产品？
三大品牌都可以。要减少维护成本请选择正规渠道正品企业级。WD Re4，ST ES.3 之类的。日立不清楚。

> 不考虑 RAID
RAID 只是个技术，有很多种实现方法，但是不论哪种方法都会涉及到人工成本，是不可能省略的。
要做离线单盘结构可以考虑 SnapRAID，放一台 12 盘热插拔的低配服务器，每次插 12 块硬盘上去，拷 9 盘的数据，剩下 3 盘让 SnapRAID 做冗余盘，可以在价格上找到平衡点。而且可以实现你说的，平时放在收纳箱中，要用的时候再拿出来拷，而且只需要拿有数据的盘出来，不需要一次插 12 块。

其实要维护简单的话，我倒是觉得最简单的还是 RAID。坏盘了，亮灯了，找人把坏硬盘拔出来，新硬盘换进去，就结束了。比你自己去折腾其他方案简单太多了。我不知道你以前遇到过的 RAID 维护有多么复杂，能不能说说看？

另外，为了让硬盘寿命错开，最好购买不同批次甚至不同品牌的硬盘混搭，减小同一时间损坏太多硬盘的风险。

还有，记得给你的 RAID 做备份。

总结一下：我觉得你提的要求是非常「反」正常操作的。你也可以看一下我司 NAS 的设计 /t/280177。

@kmdd33 我只能告诉你，正常情况下直接去软件源安装相关的软件包就结束了，不会涉及到下源码，编译，自己配置等等你提到的各种问题。还有像教程里说的把软件安装到 /data/progam/zlib 什么的，我真的是这辈子头一次见到。

至于这个帖子，我也不知道你是在什么发行版下如何安装的 PHP 以及现在是什么配置情况。
首先你装了 PHP 的 zlib 扩展了吗？

神啊，这又是谁瞎瘠薄写出来的瞎瘠薄教程啊

@ipwx 在美国，商场没有设置家庭用的洗手间，怕不是商场负责人要进哪个局子了。

我头一次听说这样的服务 6 美元月租嫌贵的。
你为了省钱而去折腾其他方案花掉的时间所对应的金钱价值，怕不是够你们看好几年的了。

难道不是 grep ？ 900M 简单过滤，10 秒钟足够了吧。

续期就是重新签署新的证书替换掉原来的。

已经生成的证书里的到期时间是无法更改的，所以不存在原地续期这种东西。

我主要想表达的观点，不是说微软的东西不好，或者闭源的东西不好等等。
我想说的是，不同的人对系统，对环境，有不同的要求和喜好。安利 OK，但是也要顾及到有些 WSL 无法满足或者无法让人满意的因素。我提出的不用 WSL 的理由，也是希望读者可以从反面的角度去观察这些事物。

@goreliu 我理解你说的。
Kernel Panic 无法解决主要是因为 Kernel 源码涉及太多东西了，本来就难以排查，这个也是正常。Windows 的内核我觉得做得很不错了，坑爹的地方在于应用层面。你发现的 Bug 上报后都处理了那是很好，可惜我并没有这个福气，Windows Update 导致无法更新系统的问题，我在整整 2 年无法更新系统后，最终只能选择重装了事。没有任何排查手段，没有任何详细的错误信息，完全无法下手去尝试任何东西，这是很无奈的。

可能你我的立场不同也有关系，你主要是运维，而我主要是开发，所以读源码对我的影响要比对你的更大一些。（不过我觉得可能有些跑题了……

@gnaggnoyil 红帽发行版和 Windows 发行版是一样的。
Linux 至少你想要新的可以选 Debian Arch，想要稳的可以选 RH。

Windows 发行版也不会给你把系统内的组件乱升级，三哥掌控以后的 Windows 除外。

Config 写源码里那更简单了，扒下源码改配置编译安装一气呵成岂不美哉。

#106 @huskar 需要长期运行，保证上下文不被打断的环境。

比如我平时业余工作需要开三五个 Excel 十多个资源管理器 二十多个其他的软件窗口，而且都是长期在用的。然后大量的繁重计算任务，会放在睡觉的时候跑。背后还要跑 Linux 虚拟机。

更新后重启没问题，但是我希望每隔两三个月所有的工作告一段落的时候，等我把虚拟机关掉，数据总结好保存关闭了，再统一打补丁重启。

#107 @goreliu 这个例子里源码的确是没有帮助的。
不过说实话，进 D 已经说明是内核附近出了什么毛病了，放到 Windows 上，IO 挂掉一样会难以调试。
这已经和软件本身的源码是否开放无关了……
我之前提的，主要是普通用户环境下的问题。

@goreliu 可能定位问题来说 Linux 不简单，但是 Windows 常常会更困难。
而且之前我说的也是开源可以让问题更容易解决，而不是更容易定位。比如 Windows 上你发现了一个 Bug，接下来怎么办，只能听天由命了吧。难道加入微软，用自己的双手改变世界？
Linux 至少你还有机会去尝试解决问题，当然我们先不说有没有能力解决。这我不认为是误区，而是开放源代码以后可以推导出的结论。

至于你提到的复现，我也可以来说说。Linux 定制性很强没错，但是结构比 Windows 简单多了。把系统打成镜像，然后替换法，加减法，至少你是「可以」去想办法缩小问题范围的。
Windows 呢，当然也可以先打成镜像，但是由于驱动的关系，你只应该在原始硬件上启动镜像（放进 VM 重装了驱动说不定就没的复现了）。然后你怎么定位问题呢，比如我自己遇到过的 Windows Update 突然报错无法升级的问题，你能把自动更新组件删了重装吗？

庞大用户群的确是优势，但不总是能解决问题。比如我之前遇到的 /t/444426 全球有多少人遇到过呢……最后问题还是没根治，都是靠 Workaround 来解决的。

说了这么多，其实并不影响我是重度 Windows 用户这个事实。只不过他原本可以做得更好的……