Ship of Theseus 條目的趣事

Hacker News Daily 上看到「0% of the phrases of the original Wikipedia "Ship of Theseus" article remain (twitter.com/depthsofwiki)」這篇,引用的是這則 tweet:

一開始掃過「Ship of Theseus」這個條目還沒有感覺,想偷懶發現有中文版的條目「忒修斯之船」:

1世紀時的希臘作家普魯塔克提出了這個問題:如果忒修斯的船上的木頭逐漸被替換,直到所有的木頭都不是原來的木頭,那這艘船還是原來的那艘船嗎?這類問題現在被稱做「忒修斯之船」。

回到原來的 tweet 上看才笑了出來。

另外補充一下,「」這個字念「特」,應該會有人想查,這邊附上連結。

Wikimedia 新計畫:WikiFunctions

Wikimedia 的新計畫 WikiFunctions:「Introducing Wikifunctions: first Wikimedia project to launch in a decade creates new forms of knowledge」。

官方的說明中提到 WikiFunctions 是提供給 Wikimedia 其他的計畫用的程式碼:

Wikifunctions is a Wikimedia project for everyone to collaboratively create and maintain a library of code functions to support the Wikimedia projects and beyond, in the world's natural and programming languages.

這樣有點抽象,看「Wikifunctions:Catalogue」這邊的範例會比較具體一點,可以看到都是實作很基本的功能,像是「Function: To Uppercase」。

Hacker News 上也有討論:「Wikifunctions (wikimediafoundation.org)」,在 id=38549081 這邊有人比較清楚的說明了要解決的問題:

A lot of Wikipedia sites have scripts embedded in the wikitext which automatically generate or transform information on a page, e.g. automatically performing unit conversions to generate text like "I would walk 500 miles (804.67 km)", performing date math to automatically generate and update a person's age based on their birthdate, or querying structured data from Wikidata [1] to display in an infobox. One example of these scripts is the {{convert}} [2] template on the English Wikipedia.

Initially, these scripts were written in MediaWiki template logic [3], and were maintained individually on each wiki. This quickly proved unmaintainable, and some of those scripts were rewritten in Lua using the Scribunto extension [4], but these were still per-wiki, and there were frequently issues where different wikis would copy scripts from each other and introduce their own incompatible features.

The WikiFunctions project is an attempt to centralize development of these scripts, much like how Wikimedia Commons [5] centralizes hosting of freely licensed images and other media.

MediaWiki 本身的 template engine 還是有極限,所以很多的需求會希望使用程式語言開發,一方面是比較好維護,另外一方面是效率也比 template engine 硬幹來的好。

先前大家在 MediaWiki 上比較常用的方案是透過 Extension:ScribuntoLua script,而這個 extension 後來變得太重要 (好用),直接包進 MediaWiki 了。

拿個例子來說,常見的引用功能 Template:Citation 裡面直接是透過模組實作:

<includeonly>{{#invoke:citation/CS1|citation
|CitationClass=citation
}}</includeonly><noinclude>
{{Documentation}}
</noinclude>

而這邊的 #invoke 就是去使用「Module:Citation/CS1」這邊的 Lua 程式。

目前的架構上面,每個語言的 Wikipedia 都需要使用 Lua 維護自己的 Module:*,而 WikiFunctions 計畫則是希望能夠整合起來,算是重新打造基礎建設的工程。

目前看了一些 WikiFunctions 的實作,主要是以 PythonJavaScript 為主。

這樣看起來,技術上是蠻有機會讓 Scribunto 退役,但實際上要不要這樣推還沒查到討論,在 Wikifunctions:FAQ 這邊則是沒提到 Scribunto,不確定是不是想雙軌跑...

改善 Wikipedia 的 JavaScript,減少 300ms 的 blocking time

Hacker News 首頁上看到「300ms Faster: Reducing Wikipedia's Total Blocking Time」這篇,作者 Nicholas RayWikimedia Foundation 的工程師,雖然是貼在自己的 blog 上,但算是半官方性質了... 文章裡面提到了兩個改善都是跟前端 JavaScript 有關的。

作者是透過瀏覽器端的 profiling 產生火焰圖,判讀裡面哪塊是大塊的問題,然後看看有沒有機會改善。

先看最後的成果,可以看到第一個 fix 讓 blocking time 少了 200ms 左右,第二個 fix 則是少了 80ms 左右:

第一個改善是從火焰圖發現 l._enable 吃掉很多 blocking time:

作者發現是因為 find() 找出所有的連結後 (a 元素),跑去每一個連結上面綁定事件造成的效能問題:

The .on("click") call attached a click event listener to nearly every link in the content so that the corresponding section would open if the clicked link contained a hash fragment. For short articles with few links, the performance impact was negligible. But long articles like ”United States” included over 4,000 links, leading to over 200ms of execution time on low-end devices.

但這其實是 redundant code,在其他地方已經有處理了,所以解法就比較簡單,拔掉後直接少了 200ms:

Worse yet, this behavior was unnecessary. The downstream code that listened to the hashchange event already called the same method that the click event listener called. Unless the window’s location already pointed at the link’s destination, clicking a link called the checkHash method twice — once for the link click event handler and once more for the hashchange handler.

第二個改善是 initMediaViewer 吃掉的 blocking time,從 code 也可以看到問題也類似,跑一個 loop 把事件掛到所有符合條件的元素上面:

這邊的解法是 event delegation,把事件掛到上層的元素,就只需要掛一個,然後多加上檢查事件觸發的起點是不是符合條件就可以了,這樣可以大幅降低「掛」事件的成本。

這點算是常用技巧,像是 table 裡面有事件要掛到很多個 td 的時候,會改成把一個事件掛到 table 上面,另外加上判斷條件。

算是蠻標準的 profiling 過程,直接拉出真實數據來看,然後調有重大影響的部分。

維基基金會 (包括維基百科) 的官方服務狀態頁

看到「Announcing www.wikimediastatus.net」這個,維基基金會相關服務的官方狀態頁:「www.wikimediastatus.net」。

從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。

看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生),另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量,可以預期大多數應該都是維基百科相關的服務...

不過大多數的量應該都是從 cache server 吐出去,不知道有沒有後端 PHP loading 的數字...

維基基金會對中國大陸維基人用戶組的行動 (WMCUG)

在『維基媒體基金會出手清除多名「中國大陸維基人用戶組」成員。包括封禁其在全球所有維基媒體基金會項目的帳號,或是拔除在中文維基百科的管理員權限。』這邊看到的消息,看起來目前都還在進行中,所以這幾天還可以繼續等看看消息。

中文版維基百科的管理群裡面被中國政府以及共青團伸手進來的事情是眾所皆知,只是先前維基基金會一直都是抱持沒有確切證據不處理的態度。

這次官方的正式聲明是由 Maggie Dennis 署名 (法務部門 VP),可以參考「Office actions/September 2021 statement」(英文版) 與「基金會行動/2021年9月聲明」(中文翻譯版本)。

相關的拔權記錄可以在「Special:Log/WMFOffice」這邊看到,這邊的時間應該是 UTC,可以看到還有陸陸續續在拔。另外在「Wikipedia:2021年基金會針對中文維基百科的行動」這邊也有一些記錄。

看到連 Outlookxp 都被拔了,總算是出手了啊...

另外補充一下在 mailing list 上看到的資料,原始的 Twitter 已經刪除,但 Internet Archive 上面還有備份:

https://web.archive.org/web/20210914024812/https://twitter.com/Philip_Tzou/status/1437543054043275265

Wikimedia 弄了自己的 Mattermost

Wikimedia (維基百科後面的基金會) 又多了一個溝通工具:「Introducing Wikimedia Chat!」。

最傳統的方式是在 wiki 的 Talk 頁上溝通 (現在看起來還是有些正式的投票討論需要走這個方式),但那個界面用起來真的頗痛苦... 一般的社群討論還是會在其他工具上進行。

先前有晃進去看過的平台應該是 IRC 與 Telegram 群組,不過後來因為量太大就閃出來了,另外這邊有提到 SlackDiscordFacebook

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.

在 Unix 環境裡各種奇怪名稱的原因說明

Hacker News Daily 上看到的,DebianWiki 上有一頁整理了很多「比較特別的」軟體或是指令的名稱由來:「WhyTheName」。

像是 Git

git
(distributed VCS) semi-arbitrary short word

不過這邊不像維基百科會要求「可供查證」,裡面大多都沒有引用來源,真的要引用前最好還是去其他地方確認過...

Blockchain 的使用時機

這兩則可以一起看,首先是 Jimmy Wales 對於提議用 blockchain 記錄維基百科的回應:

另外一個是 xkcd 最近的酸圖:

腦袋裡又瞬間冒出「詐騙集團」這個詞彙 XDDD