report

Backblaze 的 2024Q2 硬碟報告

Backblaze 的 2024Q2 硬碟報告有些新的花樣：「Backblaze Drive Stats for Q2 2024」。

先大概掃一下文字的部分，可以看到 HGST 這邊的 HUH721212ALN604 有狀況，用季計算的 AFR 偏高 (但還沒高到觸發到整個生命週期的 AFR 值)：

An HGST surprise: Over the years, the HGST drive models we have used performed very well. So, when the 12TB HGST (model: HUH721212ALN604) drive showed up with a 7.17% AFR for Q2, it’s news. Such uncharacteristic quarterly failure rates for this model actually go back about a year, although the 7.17% AFR is the largest quarterly value to date. As a result, the lifetime AFR has risen from 0.99% to 1.57% over the last year. While the lifetime AFR is not alarming, we are paying attention to this trend.

比較有趣的是多了幾張圖，用四象限分類可以更清晰的看出不同型號的情況：

另外還有依照時間變化的樣子：

這樣看起來更直覺了，比起之前對表格對半天方便不少，不過少了信賴區間的資訊，要注意硬碟的量...

Backblaze 的 2024Q1 硬碟報告

Backblaze 放出 2024Q1 的硬碟報告：「Backblaze Drive Stats for Q1 2024」。

往後拉可以先看到這張，直接對品牌分析：

可以看到一開始是 HGST 最低，後來變成 WDC 比較低。(因為 WDC 把 HGST 的很多產品線都改到 WDC 的企業級品牌下了)

另外是這張，有比較細一點硬碟型號資訊：

可以看到 WDC 這邊都是 WUH 開頭，都是 HGST 之前的型號。看起來後來就不太買 WDC 的消費級硬碟了？

對於想要找耐用一點的傳統硬碟 (統計上來說) 還是蠻好用的一份報告，而且定時會更新...

Netflix 放出了 2023 上半年一萬八千部的播放統計資料

在「What We Watched: A Netflix engagement report (netflix.com)」這邊看到的，Netflix 的文章在「What We Watched: A Netflix Engagement Report」這邊，標題提到的 Excel 報告在 What_We_Watched_A_Netflix_Engagement_Report_2023Jan-Jun.xlsx 這邊。

在 Hacker News 上的留言 id=38621625 有提到這是 Writers Guild of America 的聯合罷工 (參考英文維基百科的「2023 Writers Guild of America strike」或是中文維基百科「2023年美國編劇協會大罷工」) 所協商出來的成果：

This is an outcome of the WGA strike negotiations. Now writers (and actors, and anyone else) can use this information to better negotiate their worth with studios, rather than it being 1-sided. All other streaming services should be following suit soon.

在「What We Won」這邊可以看到關於 transparency 的部分：

Streaming data transparency: Companies agree to provide the Guild, subject to a confidentiality agreement, the total number of hours streamed, both domestically and internationally, of self-produced high budget streaming programs (e.g., a Netflix original series). Aggregated information can be shared.

打開 Excel 檔可以看到 Netflix 就放出最低限度的資料，但就如同 comment 提到的，這份資料以及足以讓很多人有機會反過來談更好的合約。

另外一方面，也可以預期這份公開資料交叉其他的 metadata 可以分析出一些有趣的東西？

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 下面，有點不太習慣，但之後用久了應該就會習慣了。其他的修一修改一改都會動了...