幹壞事是進步最大的原動力
看到「Announcing www.wikimediastatus.net」這個，維基基金會相關服務的官方狀態頁：「www.wikimediastatus.net」。
從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。
看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生)，另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量，可以預期大多數應該都是維基百科相關的服務...
不過大多數的量應該都是從 cache server 吐出去，不知道有沒有後端 PHP loading 的數字...
在『維基媒體基金會出手清除多名「中國大陸維基人用戶組」成員。包括封禁其在全球所有維基媒體基金會項目的帳號，或是拔除在中文維基百科的管理員權限。』這邊看到的消息，看起來目前都還在進行中，所以這幾天還可以繼續等看看消息。
中文版維基百科的管理群裡面被中國政府以及共青團伸手進來的事情是眾所皆知，只是先前維基基金會一直都是抱持沒有確切證據不處理的態度。
這次官方的正式聲明是由 Maggie Dennis 署名 (法務部門 VP)，可以參考「Office actions/September 2021 statement」(英文版) 與「基金會行動/2021年9月聲明」(中文翻譯版本)。
相關的拔權記錄可以在「Special:Log/WMFOffice」這邊看到，這邊的時間應該是 UTC，可以看到還有陸陸續續在拔。另外在「Wikipedia:2021年基金會針對中文維基百科的行動」這邊也有一些記錄。
看到連 Outlookxp 都被拔了，總算是出手了啊...
另外補充一下在 mailing list 上看到的資料，原始的 Twitter 已經刪除，但 Internet Archive 上面還有備份：
Wikimedia 收到通報，有一個使用者變身成其他使用者，目前調查仍在進行中，但合理的保護措施包括了將所有使用者都 logout (也就包括了維基百科)：「Logging everyone out」。
事件的後續追蹤在「User authentication security issue (Oct 1)」這張 ticket 進行中，裡面有看到另外一張 ticket 被提到：「1.36.0-wmf.11 deployment blockers」，但目前看起來還沒有完全確認相關性...
目前只能先等看看了，只能說還在進行中...
Wikimedia (維基百科後面的基金會) 又多了一個溝通工具：「Introducing Wikimedia Chat!」。
最傳統的方式是在 wiki 的 Talk 頁上溝通 (現在看起來還是有些正式的投票討論需要走這個方式)，但那個界面用起來真的頗痛苦... 一般的社群討論還是會在其他工具上進行。
先前有晃進去看過的平台應該是 IRC 與 Telegram 群組，不過後來因為量太大就閃出來了，另外這邊有提到 Slack、Discord 與 Facebook：
You can now see Wikimedia-related discussion groups in Slack, Discord, Telegram, Facebook, and many more.
這些平台都還是放在外部，就會有很多隱私上的考量：
Besides being scattered and inaccessible to people who don’t have accounts in those platforms (for privacy reasons for example), these platforms use proprietary and closed-source software, are outside Wikimedia infrastructure and some harvest our personal data for profit.
freenode 上面的 IRC 算是相對起來比較開放，但還是少了不少功能，所以就自己架了 Mattermost 出來：
IRC on freenode.net is a good alternative but it lacks basic functionalities of a modern chat platform. So we created Wikimedia Chat, a Mattermost instance hosted in Wikimedia Cloud.
比較特別的是超過 90 天的記錄會被砍掉？不太懂這邊的邏輯...
As a Wikimedia Cloud project, all of discussions, private and public are covered by Code of conduct in technical spaces and due to Wikimedia Cloud privacy policy all discussions older than ninety days will be deleted.
在 Hacker News Daily 上看到的，Debian 的 Wiki 上有一頁整理了很多「比較特別的」軟體或是指令的名稱由來：「WhyTheName」。
像是 Git：
git
(distributed VCS) semi-arbitrary short word
不過這邊不像維基百科會要求「可供查證」，裡面大多都沒有引用來源，真的要引用前最好還是去其他地方確認過...
這兩則可以一起看，首先是 Jimmy Wales 對於提議用 blockchain 記錄維基百科的回應：
We already store data. In a database. It works well.
— Jimmy Wales (@jimmy_wales) February 10, 2020
另外一個是 xkcd 最近的酸圖：
腦袋裡又瞬間冒出「詐騙集團」這個詞彙 XDDD
在 Hacker News Daily 這邊看到，英文版維基百科有一套列表，整理出「重要」的條目：「Wikipedia:Vital articles」。
目前的列表有五個層級，從 Level 1 到 Level 5，後面的 Level 包含了前面 Level 的文章：
看到的第一個問題就是這些列表怎麼產生的，這點在 Wikipedia talk:Vital articles/Frequently Asked Questions 裡面有提到列表的歷史：這是 2004 年由 David Gerard 發起，之後擴大到社群並且分不同等級。而這也說明了這些列表示人工選擇的，而不是透過演算法推薦的：
The English Wikipedia Vital Articles list was originally created in August 2004 by David Gerard as an adaptation of the metawiki List of articles every Wikipedia should have. Since then, the Vital Articles list has undergone numerous revisions by multiple editors, and has expanded to include 5 different levels of vitalness.
然後選擇的標準是「要了解這個領域不可或缺的條目」：
A vital article is one considered essential to the subjects listed. For example, it would be difficult to discuss Science without the scientific method, History without World War II, Language without Grammar, Earth science without Geology, or Civics without Democracy. Individuals within the People section represent the pinnacles of their field, such as Albert Einstein in "Inventors and scientists" or William Shakespeare in "Authors". In sections such as those pertaining to People, History or Geography, weight is given to some articles to produce a more diverse, global list.
這些列表其中一種用法是「想要了解某個領域」，但剛剛翻了一下 Level 1 與 Level 2 可以發現似乎太少，看起來 Level 3 的資料算是個還不錯的起點...
在 Hacker News Daily 上看到的資料，整理了 PostgreSQL 上不要使用的功能：「Don't Do This」，而且是放在官方網域 wiki.postgresql.org 上。
裡面這些想法不知道出處是哪邊... 有不少功能算是 PostgreSQL 特有的功能 (以 open source RDBMS 這個領域來看)，而且大概也還想的到用的場景，你卻在上面叫大家不要用，再寫的時候大概是吸了一批很純的，已經不知道要從哪邊開始吐槽...
要看的話連同 Hacker News 上的留言一起看會比較有前因後果：「https://news.ycombinator.com/item?id=19817531」。
前幾天在「Amazon Lightsail 降價...」這篇文章提到了 Lightsail 這波降價還蠻有競爭力的，但之前看過「Is the fact that Lightsail instances are just renamed T2 instances that run on CPU credits actually documented anywhere?」這篇，大概知道 Lightsail 後面其實就是 t2 系列的機器，只是在這次 t3 出來後的改版不知道有沒有順便一起改...
前幾天直接把 blog + wiki 整個搬過去看看。本來在 Vultr 的主機是 1GB RAM，就挑了對應的方案搬過去... 如果還是 t2 的話，應該就會是 t2.micro 的機器。
由於搬家前面一天都在弄各種環境，所以應該累積了不少 CPU credit，實際的情況還是要等 DNS 指過來超過一天後才會知道。在剛剛跑了一整天，把 CPU credit 吃差不多後確認了，應該還是 t2.micro，baseline 在 10% (被降速了)：
這樣的話就維持在 Vultr 好了... CPU 資源看起來還是用超過了。
去年十一月出 PHP 7.2，現在已經更新到 7.2.5，各家軟體的相容性也都修的差不多了，差不多該升級了。
在「PHP 7.2 的效能改善」這邊有提到與 PHP 7.1 的效能改善主要來自於同時間有多人同時存取時的最佳化。
同樣 wiki 也跟著更新了，來看看效果如何...