report

uBlock Origin 1.48.0 的改善

Hacker News 上看到「uBlock Origin 1.48 adds readiness status, code viewer, and other fixes (github.com/gorhill)」這則消息，uBlock Origin 在 1.48 有個蠻重要的 UI/UX 改善 (Readiness status at browser launch)。

uBlock Origin 預設會搭配「工人智慧」維護的列表，這些列表通常都不小，在剛開瀏覽器，還在讀取的過程中去看網站會遇到阻擋不完整的情況。

先前沒有辦法知道這個問題，在這版加上了對應的 icon color 來解決，黃色表示還在讀：

這時候跑去逛網站的話會出現驚嘆號：

讀取完後 icon 會變成標準的紅色，但驚嘆號仍然會留著，表示這個頁面未必有完整過濾：

正常有阻擋的則是這樣：

理論上可以減少 bug report XDDD

To reduce the number of reports caused by this issue which is outside of uBO's control, uBO's toolbar icon will now reflect its readiness status at browser launch.

對西洋棋選手 Hans Niemann 的調查

前幾天在「用情趣用品在西洋棋比賽裡面傳遞摩斯電碼作弊」這篇裡面有提到目前對 Hans Niemann 的調查都還在進行，現在 Chess.com 先丟出調查報告了：「Hans Niemann Report」，另外 Hacker News 上也有討論：「The Full Chess Cheating Report of Hans Neiman (chess.com)」。

PDF 的 summary 開頭就提到分析了線上的對奕記錄作弊的比率比起 Hans Niemann 所承認的高很多：

We present evidence in this report that Hans likely cheated online much more than his public statements suggest. However, while Hans has had a record-setting and remarkable rise in rating and strength, in our view there is a lack of concrete statistical evidence that he cheated in his game with Magnus or in any other over-the-board (“OTB”)—i.e., in-person—games. We are presenting our findings here and will cooperate with FIDE on any further investigation.

除了棋局上的記錄，在後面「How Cheat Detection Works」這個章節也提到了很多額外的 event log，像是視窗切換之類的資訊。

然後 Chess.com 也宣佈撤回賽事邀請，並且停權：

We uninvited Hans from our upcoming major online event and revoked his access to our site based on our experience with him in the past, growing suspicions among top players and our team about his rapid rise of play, the strange circumstances and explanations of his win over Magnus, as well as Magnus’ unprecedented withdrawal. In order to have more time to investigate the OTB situation and our own internal concerns, we uninvited Hans from our event and prevented his access to Chess.com. We are open to continuing a dialogue with Hans to discuss his status on Chess.com.

先有一個組織跳出來下刀了...

Kagi 的宗教戰爭：Emacs 與 Vi

目前都是用 Kagi 當作預設的搜尋引擎，然後 Kagi 習慣每個禮拜會給一個 Changelog... 而這個禮拜的 Changelog 是這樣：

我好像看到了什麼不得了的東西：

Searching for emacs redirects to vi #327 @yjp20

然後 bug report 裡面提到了他會在搜尋 Emacs 時提示 Vi：

然後搜尋 Vi 時提示 Emacs：

這是想要掀起什麼宗教戰爭嗎 XDDD

獨立遊戲創作者推出 Linux 版的好處

標題不知道怎麼下，大概就是這樣...

從 Hacker News 首頁上翻到的，以這個 upvote 數量來看，應該會收到今天的 Hacker News Daily 上：「Despite having just 5.8% sales, over 38% of bug reports come from Linux (reddit.com)」。

作者是一位獨立遊戲開發者，在兩年前推出了「ΔV: Rings of Saturn」這款遊戲，並且也發佈了 Linux 版。

作者先就數字來比較，他賣出了 12000 套，其中 700 套是 Linux 玩家；另外他收到了 1040 個 bug report，其中大約 400 個是從 Linux 玩家回報的：

As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.

That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.

看文章時可能會覺得「Linux 玩家真難伺候」，但實際上作者講到，這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上)，其他的 bug 其實是所有平台都會發生：

A lot of extra work for just 5.8% of extra units, right?

Wrong. Bugs exist whenever you know about them, or not.

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]

原因是 Linux 社群在參與各種 open source project 養成的習慣，會盡可能把各種資訊講清楚，並且找出可以重製問題的方式：

The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

But that’s not all. The report quality is stellar.

與一般玩家的回報方式完全不同，Linux 玩家很習慣就會附上基本的環境資訊，系統紀錄，甚至有時候還會包括 core dump 與 reproducible steps：

I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.

And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

不知道有沒有遇到回報 GDB 資訊的...

很特別的分享 XDDD

Backblaze 的 2019 年度硬碟報告

Backblaze 丟出去年的報告了：「Backblaze Hard Drive Stats for 2019」。

WD/HGST 的還是最耐用，再來是 Toshiba 的，最後是 Seagate 的。

不過有一些硬碟沒有列到表上，像是「Seagate 16 TB Drives」這組因為 2019Q4 才剛裝上去，所以才 1440 drive days，因此還沒到門檻所以沒放進報告，但就 Backblaze 測試起來看起來是個好的開始：

In Q4 2019 we started qualifying Seagate 16 TB drives, model: ST16000NM001G. As of the end of Q4 we had 40 (forty) drives in operation, with a total of 1,440 drive days—well below our 5,000 drive day threshold for Q4, so they didn’t make the 2019 chart. There have been 0 (zero) failures through Q4, making the AFR 0%, a good start for any drive. Assuming they continue to pass our drive qualification process, they will be used in the 12 TB migration project and to add capacity as needed in 2020.

再來是把 2017/2018/2019 擺在一起看：

馬上可以看到的是 AFR 上升了不少，一個是因為 8TB 系列的硬碟進入中年期，另外是 Seagate 12TB 硬碟的問題：

The total AFR for 2019 rose significantly in 2019. About 75% of the different drive models experienced a rise in AFR from 2018 to 2019. There are two primary drivers behind this rise. First, the 8 TB drives as a group seem to be having a mid-life crisis as they get older, with each model exhibiting their highest failure rates recorded. While none of the rates is cause for worry, they contribute roughly one fourth (1/4) of the drive days to the total, so any rise in their failure rate will affect the total. The second factor is the Seagate 12 TB drives, this issue is being aggressively addressed by the 12 TB migration project reported on previously.

所以大原則還是跟以前差不多，沒有時間特別研究的話就先往 WD/HGST 這邊找...

GitHub 在 2/28 遭受的攻擊...

GitHub 在 2/28 遭受 DDoS 攻擊，蠻快就把事故報告丟出來了：「February 28th DDoS Incident Report」。

不過跟 GitHub 其他文章不太一樣，這篇算是 PR 稿吧，簡單來說就是花錢買 Akamai Prolexic 的過濾服務解決... Akamai 方的 PR 稿則是在「Memcached-fueled 1.3 Tbps attacks - The Akamai Blog」這邊可以看到。

17:21 UTC 發現問題，然後判斷超過 100Gbps，所以 17:26 決定讓 Akamai Prolexic 接管過濾：

At 17:21 UTC our network monitoring system detected an anomaly in the ratio of ingress to egress traffic and notified the on-call engineer and others in our chat system. This graph shows inbound versus outbound throughput over transit links:

Given the increase in inbound transit bandwidth to over 100Gbps in one of our facilities, the decision was made to move traffic to Akamai, who could help provide additional edge network capacity. At 17:26 UTC the command was initiated via our ChatOps tooling to withdraw BGP announcements over transit providers and announce AS36459 exclusively over our links to Akamai. Routes reconverged in the next few minutes and access control lists mitigated the attack at their border. Monitoring of transit bandwidth levels and load balancer response codes indicated a full recovery at 17:30 UTC. At 17:34 UTC routes to internet exchanges were withdrawn as a follow-up to shift an additional 40Gbps away from our edge.

就這樣而已，完全就是 PR 稿 XDDD

總算把手上的 Trac 1.0 升級到 1.2 了...

就如同上一篇提到的，Trac 在 1.1.1 後新增了 time 格式，所以本來的 DateFieldPlugin 有些資料要轉換。我這邊只有用在 Due Date，所以就是轉 due_date 的資料而已。

先把 due_date 都改成 due_date_bak：

UPDATE ticket_custom SET name = 'due_date_bak' WHERE name = 'due_date';

然後重新計算資料，這邊是因為所有的系統都是 UTC，所以直接轉就可以了：

INSERT INTO ticket_custom (ticket, name, value) SELECT ticket, 'due_date', LPAD(UNIX_TIMESTAMP(STR_TO_DATE(value, '%Y-%m-%d')) * 1000000, 18, '0') FROM ticket_custom WHERE name = 'due_date_bak';

而我的 Report 有用到 due_date 欄位的東西，本來是 c.value 直接輸出，現在要改成：

FROM_UNIXTIME(CONVERT(c.value / 1000000, UNSIGNED INTEGER), '%Y-%m-%d') AS due_date

Trac 1.2 相較於 1.0 最不習慣的地方應該是修改界面的位置改變了，現在 Add Comment 變成在 Modify 下面，有點不太習慣，但之後用久了應該就會習慣了。其他的修一修改一改都會動了...

PostgreSQL 10 發表

PostgreSQL 10 發表，有不少重要的功能 (進步)：「PostgreSQL 10 Released」。

首先提到的是 Logical Replication：

Logical Replication - A publish/subscribe framework for distributing data

以往內建的 replication 是 block level change (同步哪個 block 改變的內容)，對於版本不同的 PostgreSQL 就會痛。所以在 10 之前，想要處理 PostgreSQL 版本不同的問題都會使用第三方套件 (一種常見的情境就是資料庫的版本升級)。在 10 內建支援 Logical Replication 後就不需要掛其他套件了：

Logical replication extends the current replication features of PostgreSQL with the ability to send modifications on a per-database and per-table level to different PostgreSQL databases. Users can now fine-tune the data replicated to various database clusters and will have the ability to perform zero-downtime upgrades to future major PostgreSQL versions.

於是就可以達到 zero-downtime upgrade，這對於商業維運考量是個很重要的進展。

另外一個是 Improved Query Parallelism (在 9.6 就有，現在又再改善了)，針對可平行化的 CPU-bounded SQL query 可以利用多 CPU 大幅加速，這點也是目前在 MySQL 上還沒看到的：

PostgreSQL 10 provides better support for parallelized queries by allowing more parts of the query execution process to be parallelized. Improvements include additional types of data scans that are parallelized as well as optimizations when the data is recombined, such as pre-sorting. These enhancements allow results to be returned more quickly.

上面提到這兩點其實對於某些需求是相輔相成的。

因為很多報表分析是可平行化的 CPU-bounded SQL query，但以前在 RDBMS 都不能被平行運算，於是很多單位就會想要倒出來到其他類型的資料庫運算 (以現在比較紅的產品，像是 Amazon Redshift、Amazon Athena，或是 BigQuery，甚至是丟進 ELK 裡)。但你用 PostgreSQL 又會痛在沒辦法很方便的把資料同步拉出來... (於是就會稍微妥協，用 cron job 每天倒資料)

現在 10 的這兩個功能剛好從兩個面向解決：一個是對於剛開使用 PostgreSQL 的人，他們可以繼續只用 PostgreSQL 撐久一點，因為報表需求的 SQL query 快很多；另外一方面也讓目前用 cron job 每天倒資料的人有了同步的選擇 (用 replication 同步到其他系統上)。

再來是 Quorum Commit for Synchronous Replication 這個功能，把分散式架構中需要「正確性」的底層技術做起來：

PostgreSQL 10 introduces quorum commit for synchronous replication, which allows for flexibility in how a primary database receives acknowledgement that changes were successfully written to remote replicas. An administrator can now specify that if any number of replicas has acknowledged that a change to the database has been made, then the data can be considered safely written.

整體來說，PostgreSQL 10 有非常多進步，而且這些進步對於商業營運考量都很有幫助...

歐盟對於盜版是否帶來傷害的研究

歐盟在 2014 年做了關於盜版與銷量的研究，結果一直被壓到最近才發表出來 (於是就大概可以猜到結論了...)：「EU Piracy Report Suppression Raises Questions Over Transparency」。

“In general, the results do not show robust statistical evidence of displacement of sales by online copyright infringements,” the study notes.

甚至：

The study found that piracy had a slightly positive effect on the videogames industry, suggesting that those who play pirate games eventually become buyers of official content.

另外也描述了現有電影與 TV-series 定價策略偏高：

“Overall, the analysis indicates that for films and TV-series current prices are higher than 80 per cent of the illegal downloaders and streamers are willing to pay,” the study notes.

難怪被壓著...

VPN 的評價

文章的作者試了很多家 VPN 服務，然後文章的標題有點長，有種輕小說的感覺...：「I tested the most recommended VPN providers using my credit card to find the best ones — and which ones you should avoid.」。

不過這種文章有很多東西很主觀，大家心裡有個底就是了...

作者比較滿意的是 TunnelBear 與 OVPN 這兩家，也許等手上 PIA 到期的時候再試看看要怎麼選好了，畢竟 PIA 還是目前最便宜的方案。