因为知道 PHP 和 sql 注入危害的人已经年纪大了，不是做管理就是被优化了，作为码农生力军的新入门菜鸟继续重复着这些错误。
什么 docker 微服务，对黑客的拖库和挖矿来说，影响其实并不大，而且部署 docker 的人往往更疏于关注系统更新和补丁。

除了上面提到的 regex101.com ，补充个 debuggex.com 的图形化显示也能较好辅助理解。

正则这东西，真是只有在所有可以使用的正则的地方经常使用，才能体现投入产出比。
但是麻烦的就是在 php,python,grep,vim,sed 各类可以使用的地方，他们的正则在细微处总有差异，特别在转义方面有着各自的坚持，实在是令人抓狂。

我也是最近才发现 Mysql/MariaDB 的 innodb 开启的 Page Compression ，也是用到了文件系统的这种 sparse file 特性，而象 ext3 和 ntfs 这样都老文件系统也一早有这种特性了。

我觉的很多讨论都是偏移了方向了。这里是跟什么纠正发音的完全不同性质，而是在特定环境下，混用日常用语和术语令人不快的问题。
在作为专业论坛里，的确就是应该使用不会导致歧义的术语进行问题讨论，你作为程序员如果混用了一些明显是会导致歧义的日常用语，一来就是显得自己专业素养不够，二来就是显得不尊重讨论氛围，被人指摘无可厚非。
你如果试试看投稿论文里把 internal storage 叫做内存，看看会不会给编辑刷下来？

两者应该都掌握。如果一个工作不能几行 shell 就搞定，那就上 python 。
如果你 shell 熟练，会发现很多事情 python 写一大段代码，也就是 shell 里跑几个命令用管道连接就搞定了。

压缩包都有 CRC 校验的，里面的数据损坏就会导致部分甚至所有文件无法解压。
如果是想要快速比较不同目录（硬盘）下数据，可以对所有文件做 HASH ，然后进行 HASH 比较即可。Linux 下有 hashdeep 之类对目录 Hash 的工具。

开始设计的方案肯定是追求一致性的。当性能问题严重才会考虑冗余数据来提高性能。如果你的数据库支持物化视图就可以考虑用它来做统计数据会较为省心，如果性能仍然有问题，这个数据量你就要从需求上考虑，是否真的对实时的统计数据有必要的需求，因为如果不是为了金融级别的结算等需求，应该不会有人介意这个统计数据其实是若干分钟甚至小时前的 ETL 加工数据，那方案就多了去了。

@dfgxcvbcv
例如 centos 、RHEL 系列。象 centos7 系列在 2014 年出来带的 python 一直到现在就是 2.7.5 版，就只是一直 backport 各种补丁，更改的只是打包序号。根本就不会出现由于软件包因为版本升级导致依赖出问题这类事情。

如果这个发行版 update 会变更软件包的版本，那你就不应该选这个发行版作为服务器操作系统。

个人感觉，传统关系型数据库只能应付中小型数据量，单一标签查询需求的标签系统，如果是千万级以上数据量，有复合查询需求的，用关系型数据库实现性能会很差。

setacl +1

如果不考虑离线情况，即用户总是联网使用付费功能，则可以考虑不对称加密方式。密钥在服务器上，客户端有公钥，素材的全体或部分用密钥加密后才保存在客户端。平时客户端用公钥解密来使用，这样就无法简单的绕过某个判断来使用完整功能了。

50 年人工智能就很可能产生重大影响，100 年后计算机冯诺依曼体系也许都不会是主流，量子计算也许都是常规电脑里的一个辅助单元了，你还想现在的软件永存？

对这种小样本、没任何科学分组的研究测试，看看就好。