Category: Recreation

KataGo 推出了人類棋譜訓練出來的 model

KataGo v1.15.0 的「New Human-like Play and Analysis」推出了用人類棋譜訓練出來的 model：

This release adds a new human supervised learning ("Human SL") model trained on a large number of human games to predict human moves across players of different ranks and time periods! Not much experimentation with it has been done yet and there is probably low-hanging fruit on ways to use and visualize it, open for interested devs and enthusiasts to try.

lightvector 列出的一些 screenshot 看起來像是試著去猜測人類的棋力可能會選擇的點，列出了同樣的棋局在 20 級、1 段與 9 段會考慮的點的差異，算是一種幫助人類理解的方式？

lite-youtube-embed

繼續清 tab，在「YouTube embeds are heavy and it’s fixable (frontendmasters.com)」這邊看到的是提出改善 YouTube 的外嵌功能 (embed)，因為 loading 太肥了。原文在「YouTube Embeds are Bananas Heavy and it’s Fixable」，裡面提到一個只有 YouTube 的 embed (iframe) 頁面就抓了 1.3MB 的資料：

On a page with literally nothing at all on it other than a YouTube Embed, we’re looking at:

32 requests
1.3 MB of data transfer
2.76s to load the page on my current WiFi connection

而「One YouTube Embed weighs almost 1.2 MB」這邊更提到了這邊的 resource 會線性疊加不會共用的：

The weight also grows linearly with every embed—resources are not shared: two embeds weigh 2.4 MB; three embeds weigh 3.6 MB (you get the idea).

測了一下 https://home.gslin.org/tmp/ytembed.html 這個，是 1.2MB transferred：

如果放兩個一樣的影片，也就是 https://home.gslin.org/tmp/ytembed2.html 的話，變成 2.4MB transferred：

所以不共用的部分的確超大，懷疑 iframe 之間不共用資源是不是跟 cache partition 的實作有關：「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」。

Anyway，所以作者提案用 lite-youtube-embed 這個套件改善：

Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster.

不過這種事情你想得到，Google 也一定想得到，全篇只講 lite-youtube-embed 的好處一定哪邊有問題。

所以翻一下 Hacker News 上，在 id=40897582 這邊就有人提到缺點了，很明顯 lite-youtube-embed 的載入速度比較慢：

The author says they don't believe that a lighter version has been shown to reduce engagement.

I, on the other hand, fully believe that.

The recommended lite-youtube-embed project page has a demo of both lite and regular players [0], and the lite version takes noticeably longer to start playing the video.

Every additional millisecond of load time will reduce engagement, and here the difference is more on the order of hundreds of milliseconds or more.

[0] https://paulirish.github.io/lite-youtube-embed/

yeah，這樣就合理了。

即使 embed 吃超多資源，但因為 YouTube 是影音網站，主要的流量還是影音的部分，利用這個方法增加載入速度，在成本結構上面可以接受，而且還可以拿到更多瀏覽資料？

但對於網站端以及使用者端就不是什麼愉快的事情，所以網站端要不要用這個套件就是看各自的取捨了。

Google Public DNS 接受法國法院的阻擋要求

看到「Google, Cloudflare & Cisco Will Poison DNS to Stop Piracy Block Circumvention」這篇，法國在 2022 年通過的體育法律反過來干涉 ISP 或是服務提供商需要配合阻擋：

Tampering with public DNS is a step too far for many internet advocates but for major rightsholders, if the law can be shaped to allow it, that’s what will happen. In this case, Article L333-10 of the French Sports Code (active Jan 2022) seems capable of accommodating almost anything.

拿文章裡面提到的 footybite.cc 測試，實際在法國開一台 Vultr 的 VPS 測試各家 Public DNS 服務，看起來目前 Google Public DNS 已經實作了，而且傳回了 RFC 8914: Extended DNS Errors 內的 EDE 16：

$ dig footybite.cc @8.8.8.8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 16 (Censored): (The requested domain is on a court ordered copyright piracy blocklist for FR (ISO country code). To learn more about this specific removal, please visit https://lumendatabase.org/notices/41606068.)
;; QUESTION SECTION:
;footybite.cc.                  IN      A

目前拿 1.1.1.1 (Cloudflare)、9.9.9.9 (Quad9) 以及 208.67.222.222 (OpenDNS) 都還沒有看到被擋。

另外實際測試，自己架設 Unbound 看起來就可以繞過去了，不知道後續會不會要求更多，像是直接要求在 internet backbone 上面過濾 DNS？(當年推 DNS over TLS 與 DNS over HTTPS 總算要派上用場了？)

另外就是看 Cloudflare 以及其他 Public DNS 服務有沒有反對的動作...

Winamp 打算要放出程式碼

在「Winamp has announced that it is "opening up" its source code (winamp.com)」這邊看到的消息，原公告則是在「Winamp has announced that it is opening up its source code to enable collaborative development of its legendary player for Windows.」這邊。

這篇公告上面的「Dec 16, 1」不知道是什麼... Anyway，預定今年九月的時候公開程式碼，在 id=40383890 這邊有提到可能的原因：

Winamp's owners have been going through financial difficulties since last year and as a result have laid off the skeleton crew they previously had maintaining Winamp (their main focus seems to be a streaming service also called Winamp for HTML5 and phones). This looks like they're willing to let the community take over maintenance for PC Winamp, which beats letting it die IMO.

銀河的歷史又翻過了一頁？

LinkedIn 決定要在平台上面弄出遊戲...

也是清連結的消息，三月中的消息，LinkedIn 想要在平台上面弄出遊戲：「LinkedIn plans to add gaming to its platform」。

會是 puzzle 類型的遊戲，而且看起來有東西了：

It will be doing so by tapping into the same wave of puzzle-mania that helped simple games like Wordle find viral success and millions of players. Three early efforts are games called “Queens”, “Inference” and “Crossclimb.”

然後當時跟 LinkedIn 發言人確認也證實了這點：

“We’re playing with adding puzzle-based games within the LinkedIn experience to unlock a bit of fun, deepen relationships, and hopefully spark the opportunity for conversations,” the spokesperson said in a message to TechCrunch. “Stay tuned for more!”

試著走向更一般性的 social network？目前 LinkedIn 上面應該都是雞湯文與 clickbait，這個變化好像有點大...

Simon Tatham 的遊戲庫

在 Hacker News 上看到「Simon Tatham's Portable Puzzle Collection (greenend.org.uk)」這個討論，會讓我注意到的點是看到 greenend.org.uk 這個網址，印象中這就是 PuTTY 官網用的 domain，而點進去看以後發現就是 PuTTY 作者 Simon Tatham 另外的小玩具：「Simon Tatham's Portable Puzzle Collection」。

裡面都是單人遊戲，有提供 JavaScript 版可以在瀏覽器上直接玩，另外也有多個不同平台的執行檔可以用。是個墮落殺時間的區域...

北韓的動畫承包團隊

2023 年的時候在北韓的 internet 上發現一台沒有設定好的伺服器，於是就有人 dump 下來分析裡面的內容，然後就發現看起來是中國的團隊轉包給北韓團隊用的 server：「What We Learned Inside a North Korean Internet Server: How Well Do You Know Your Partners?」。

像是這張圖，可以看到上面有「EKACHI EPILKA」，這查一下可以查到「株式会社エカチエピルカ」，另外也可以看到簡體中文以及韓文的說明：

雖然拼圖不夠完整，但應該是可以看出輪廓了：目前比較像的情況應該是中國拿到合約後轉包給北韓的團隊，這對於有在關注日本動畫產業的人來說應該也不算太意外，日本的動畫產業已經是高度分工，自己國家內二包三包本來就很常見，如果是先包到中國，再分包到北韓的話也不算太奇怪：

There is no evidence to suggest that the companies identified in the images had any knowledge that a part of their project had been subcontracted to North Korean animators. In fact, as the editing comments on all the files, including those related to US-based animations, were written in Chinese, it is likely that the contracting arrangement was several steps downstream from the major producers.

不過法律上就有些狀況了，北韓應該是被制裁對象...

在 virt-manager 裡面的 Windows 發出聲音

用了幾個月才發現沒聲音，花了點時間找方法測試才解決。

一般人用預設值應該是沒問題，不過我的環境比較特別，剛好不是預設值，我的 PulseAudio 輸出到 DA&T C-13 時是設定成 96kHz/24bit，而一般 Windows 預設輸出時是 44.1kHz/16bit，兩邊對不起來就沒聲音了。

找了一些文章，後來是在「Virtual machine audio setup – or how to get pulse audio working」這篇裡面講到用 virsh 直接改 XML 設定檔的方式讓 qemu 輸出到 PulseAudio 裡面轉，也就是文章裡面 Option 2 的部分。

這樣 guest OS 裡面還是跑 44.1/16，但外面輸出的時候就固定是 96/24 了。

比較奇怪的是如果 guest 裡面跑 96/16 的話聲音會破破的，不過我只是要有聲音 (不然也不會用了好幾個月才發現)，品質的問題倒是還好...

猴硐 (車站、神社、貓村)

週末搭火車去猴硐吸個貓，本篇與技術無關，另外請注意圖多。另外照片都已經丟到 Flickr 上了，也可以自己翻。

主要是因為我跟我老婆都有北北基的 TPASS ($1200/30days 的版本)，加上也放在名單裡面一陣子了，這個週六剛好天氣還不錯就從搭台鐵過去，搭區間快車，12:09 從板橋上車，13:12 就到了，早一點先到板橋站買了個台鐵便當：

這應該是最方便的交通方案了，下車時可以發現有不少外國遊客。

下車後本來是計畫要先去猴硐神社的，結果走錯方向 (往北跑)，但意外看到還蠻漂亮的河床：

然後是路上意外發現這邊也有 foodpanda 的送貨箱子：

回頭走的時候就看到一隻貓貓，看起來有點狀況，不過先前查資料的時候得知猴硐有機制在管理，應該是會有人照料：

另外看到一隻躲在陰影下面納涼的貓貓：

接著就順著地圖走找神社，不算太難找，不過我們是從猴硐路上去，然後從北 37 線下去，所以會先看到涼亭：

涼亭旁邊有說明：

下來到北 37 線後後會看到鳥居以及同樣的告示牌，如果偏好從鳥居上來的話可以從北 37 線這邊進來：

接著在遠處有看到桐花，拿起相機試著拍幾張：

接著就繼續往猴硐貓村走，先走回猴硐車站，然後從二樓的走道可以進入貓村，只要遠遠看到有一群人圍著，就大概知道有貓在那邊了... 這邊就有很多貓貓：

接著就到咖啡廳裡面吹冷氣當作猴硐這邊的最後一站，順便看看店貓：

預定的下一站是要去九份看看，先看了台鐵的發車時間，然後早了一點離開，從另外一側的樓梯下去，再多吸幾隻貓貓：

還有躲到廢棄屋子裡面的貓貓：

以及我老婆在看上面那隻貓貓，結果被其他貓貓跑過來反吸兩口，沒注意到結果後退的時候嚇到貓貓：

然後繼續下樓看到的：

以及在水塔旁邊喝水的貓貓：

最後是在車站通道上也看到一隻貓貓趟在旁邊，以及公所的告示：

對於有 TPASS 的人來說算是不錯的半天行程，要注意的是當地沒有便利超商，建議帶個裝滿水的水壺過去，或是在出發的地方先買好水。

Google 推出 Jpegli：JPEG 的 encoder 以及 decoder

在 Hacker News 上看到「Jpegli: A new JPEG coding library (googleblog.com)」，原文是「Introducing Jpegli: A New JPEG Coding Library」。

裡面是有提到檔案大小可以更小：

Our results show that Jpegli can compress high quality images 35% more than traditional JPEG codecs.

但這邊沒有講壓縮率的部分是哪個「traditional JPEG codec」比較，大概就是「WebP 的檔案大小未必比 JPEG 小...」這邊的老招了，應該是跟 cjpeg 比，如果跟 MozJPEG 比的話就未必有那麼高了。

想要寫起來的是 Hacker News 留言有提到命名的邏輯，這個 -li 結尾的用法可以看出來是 Google 蘇黎世團隊的產品：

The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.

This obviously comes out of Google Zürich.

這點還可以從其他的產品看到類似的命名，比較熟的是 Zopfli 以及 Brotli。