幹壞事是進步最大的原動力
在 Nuzzel 上看到的文章，講 PHP 裡不應該使用 empty()：「When to use empty in PHP? I’d say never」。
之前寫 PHP 時很習慣用 === 與 !== 比較，另外習慣用 is_type() 先判斷型態再去搭其他的判斷 (像是 is_array() 與 is_string() 這類型態確認)，算是避免了文章裡面提到的問題，而且也提高了程式的可讀性 (因為開發者看到 is_type() 可以預期型態)。
比較討厭的應該是偶而還是會搞混 + (數字相加) 與 . (字串串接)，還有 + 對兩個數字字串是可以操作的 (然後會傳回 int)：
$ php -a
Interactive mode enabled
php > var_dump('123' + '456');
int(579)
php >
用過都說幹 XD
看到 WordPress 的這篇「WordPress and PHP 8.0」，看起來 PHP 8.0 快要出了：
PHP 8.0 is in the final stages of its release cycle. As of the publish date of this post, version 8.0 RC5 has been released, and the final release of PHP 8.0.0 is scheduled for November 26, 2020.
官網上已經有一些資料可以看了，不過記得畢竟還沒 release，裡面的資訊還有可能會修正：「Migrating from PHP 7.4.x to PHP 8.0.x」，最重要的應該還是「Backward Incompatible Changes」這邊，可以看到這次畢竟是主版號升級，精彩的不相容性應該會搞爆不少應用程式，像是開頭就提到的，對數字與文字之間的 == 行為改變：
比較好的作法是自己先轉型再用 === 比較，這個概念在各家程式語言都類似，loose comparison 只是方便而已...
先前在「Amazon EC2 的 M6g 系列正式推出了」這邊提到了 AWS 在 Amazon EC2 上推出了以 ARM 為架構的 m6g 系列機器，剛剛看到有人拿 PHP 上的應用丟出測試的差異了：「Improving performance of PHP for Arm64 and impact on Amazon EC2 M6g instances」。
最先要注意的應該是這張：
在 PHP 7.3 的時候 Intel 平台的 m5 跑比較快，但到了 PHP 7.4 就變成 ARM 的 m6g 跑比較快了，不過這兩個版本的差異都不算太大，而到了還在開發的 PHP 8 則是出現了比較大的差距。
作者有提到主要的原因是在 PHP 7.4 之前 ARM 上不會啟用 Zend optimizer，而這個功能對效能的影響差很多，在 PHP 7.4 打開後就反轉了：
Zend optimizer is a component of the PHP runtime system that improves performance by up to 30% on a range of Zend micro-benchmarks. Before PHP 7.4 the Zend optimizer was not enabled for Arm.
而 PHP 8 的差距拉大，則是因為 PHP 有更多針對 ARM 平台的改善，像是這邊提到的 NEON 指令集：
PHP-8 plans to release in 2021 with more improvements for Arm64: an improved toupper/tolower function brings performance up by 16.5x. https://github.com/php/php-src/pull/4439
除此之外，AWS 也對 PCRE2 提供了使用 NEON 指令集的加速的 patch：
AWS has contributed changes to PCRE2 release 10.34. PCRE2 version 10.34 is used in PHP-8 to match regular expressions. PCRE2 accounted for about 8% of execution time in WordPress benchmark. The change contributed by AWS to PCRE2 vectorizes first character match and matching pairs of characters with NEON instructions: performance improves by up to 8x on M6g.
這樣可以看到 ARM 平常應該會愈來愈成熟，而更重要的是 m6g 系列機器比 m5 便宜不少：以作者測試的 {m5,m6g}.4xlarge 來看，分別是 USD$0.768/hr 與 USD$0.616/hr，大約是 20% 的差距，加上效能上的差距，C/P 值看起來是真的有到官方宣稱的 40%，這點在其他 Plurk 也測出了類似的結果：
未來除非是 binary-only 的東西，不然應該會朝著往 ARM 上面測過，再決定要怎麼選 instance type...
Twitter 上看到「PHP RFC: Unbundle ext/xmlrpc」這則消息，PHP 官方打算把 XML-RPC (也就是 git repository 裡面的 ext/xmlrpc) 拆出去，移到 PECL：
Unbundle ext/xmlrpc (i.e. move it to PECL) without any explicit deprecation.
主要的考慮是在於目前的 library 已經年久失修：
ext/xmlrpc relies on on libxmlrpc-epi, which is abandoned. Even worse, we are bundling a modified 0.51, while the latest version is 0.54.1. This is exacerbated by the fact that the system library is usually built against libexpat, but the bundled library is likely to be built against libxml2 using our compatibility layer.
另外應該也是因為 XML-RPC 用的人不多吧，投票是沒什麼玄念的 50:0，而且在 Packagist 上面也可以翻到一些用 PHP 實做的替代品，拿 xmlrpc 這個關鍵字搜了一下可以看到一些...
Twitter 上看到的通知，這個提案將 PHP 的 JSON 列為語言的必須項目，目前的狀態是 Under Discussion：「PHP RFC: Always available JSON extension」。
以前沒有引入的一個原因是因為底層使用的 library 的授權 JSON license 不是 open-source license，這對於要打包出 binary 散佈時的問題很大 (跟其他 license 衝突)：
The Software shall be used for Good, not Evil.
在 PHP 7 之後，JSON 的實做決定改用 jsond (參考「PHP RFC: Replacing current json extension with jsond」)，這邊用的是 PHP License 授權：「LICENSE」，這個因素就緩解了。
而這個提案提議拔掉 ./configure –-disable-json 關閉 JSON library 的能力，把 JSON library 變成 PHP language 的一部份：
Make it impossible to disable the JSON extension through configuration or build options. Require that JSON be built statically instead of as a shared library.
這個提案如果通過的話，對大多數人應該還是沒什麼影響，因為一般在用的版本都會裝 JSON library。而且現在會透過 Composor 管理套件，很容易就會有 dependency 會用到 JSON 而需要安裝 JSON library，問題不太大...
Rasmus Lerdorf 整理的資料 (就是生出 PHP 的那個 @rasmus)，關於平價 VPS 的測試：「Low-Cost VPS Testing」。
因為是 PHP 的大頭，所以把編 PHP 當作是 benchmark 的項目之一也不算太意外。另外還是有比較常見的 dd 與 iperf3 測試資料可以看。
算是一個挖掘的點，之後也可以租幾台測試看看...
這次的漏洞是在打 CTF (capture the flag) 的時候發現的，這個安全漏洞已經被給 CVE 編號並且修正了：「CVE-2019-11043」，回報者與官方的討論可以在「Sec Bug #78599 env_path_info underflow in fpm_main.c can lead to RCE」這邊看到。從回報的標題可以知道這次頗熱鬧的原因，是因為這次有機會 RCE (remote code execution)...
在「PHuiP-FPizdaM」這邊可以看到比較系統性的整理 (以及 exploit)，看起來雖然有不少條件，但都不算太特別的指令，如果以全世界的機器來看，應該會有不少機器中獎...
上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」)，這次是在整理機器時發現 blog 這台機器還在跑 7.2，就更新一下系統把上面的站台都換到 7.3。
蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」)，目前看到的資料都會快一些，應該是沒有太大問題，之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB，但用 opcache-status 看起來只用了 65 MB 左右)，把記憶體空間讓給其他程式用...
不過 7.4 也快出了...
跑了快一個月了，大概整理一下...
一直都有在規劃降低對 Google 服務的依賴性，最主要的是使用 DuckDuckGo 替代 Google Search (但搜尋的品質還是差一截，所以寫了一些工具幫助我在不滿意的時候可以快速切到 Google 搜尋：「在 DuckDuckGo 搜尋頁快速切換到 Google 的套件」)。
而最近在研究的另外一個服務是 Google Analytics，我只用很基本的功能 (像是熱門文章，作業系統與瀏覽器的比率這些很基本的資料)，不需要對於觀看客群有了解 (這個需要像 Google Analytics 跨站蒐集資料)，所以替代方案應該不難找...
憑著印象與一些關鍵字，找到了 Matomo，這是一套 open source 的 web analytics 服務，以前叫做 Piwik (參考「Piwik is now Matomo - Announcement」)，整個系統用 PHP + MySQL 就可以打發 (反正量不大的東西不需要拿什麼神兵利器出來，MySQL 硬塞硬算就可以了)，接著把本來 Google Analytics 的 js 換掉就行了...
跑了快一個月後感覺還 ok，基本的資訊都有...
Packagist 打算把服務丟上 AWS：「An Update on Packagist.org Hosting」。
We decided to migrate the packagist.org website to AWS as well, including the database, metadata update workers, etc. This makes it much easier to build a highly-available setup, where machines can be rebooted or even rebuilt safely without bringing down the whole site.
不知道會搬多少上去... 目前 .com 的 packagist.com 已經上 AWS 了，但 packagist.org 與主要的流量來源 repo.packagist.org 看起來都還沒。