用事實查核中心的 RSS feed 加上 IFTTT 自動通知到 Line/Telegram/... 內

事實查核中心的澄清內容其實很有趣,可以看到有哪些假消息在流傳,所以想找找看有沒有比較簡單的方法可以設通知...

事實查核中心的官網用的是 netiCRM 這個平台 (看起來底層是 Drupal),而在 HTML 頁面的開頭可以看到 RSS 1.0 的 xmlns 宣告:

  xmlns:content="http://purl.org/rss/1.0/modules/content/"

本來想說直接用 feed 接到 IFTTT 就好了,不過 HTML 頁面上沒有放 feed entry 讓閱讀器可以直接找到 feed 本身,也就是像這樣的標籤資訊:

<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Feed" href="https://blog.gslin.org/feed/" />
<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Comments Feed" href="https://blog.gslin.org/comments/feed/" />

找了一下 Drupal 的設定慣例,發現 feed 可能會放在 /rss.xml 這個位置,測了一下發現順利在 https://tfc-taiwan.org.tw/rss.xml 這邊看到 feed,接下來就可以加進 IFTTT 了:

給有興趣想要用 feed 做些事情的人參考看看,像是加到 Line 或是 Telegram 的群組裡面,或是放到 Slack channel 裡面 (Slack 裡應該可以直接在某個 channel 裡用 /feed add https://tfc-taiwan.org.tw/rss.xml 把這個 feed 加進去)。

產生模糊縮圖的 BlurHash

先從一張圖片算出大約 20~30 bytes 的字串,就可以在 API response 時快速產生出一個很模糊但是有有代表性的縮圖 (或是在 HTML 裡面放,用 javascript 產生):「BlurHash」。

從官方給的範例比較快理解:

以及:

另外也提供了展現在 app 上的效果:

有支援一些程式語言,不過看起來行動平台上的支援都是比較新的語言 (Swift & Kotlin),如果不是用這些語言而想用 BlurHash 的話就得自己整了...

另外在 Hacker News 上有翻到先前的討論:「BlurHash: Algorithm to generate compact representation of an image placeholder」,開頭就看到其他軟體的作法:

For comparison, Instagram sends ~200 byte base64 thumbnails in its API responses. It's a low-res JPEG with a fixed header to save a bit more space. This is also used to blur sensitive images. You can get even better results with webp.

這個方法就避開另外再弄一包 library 進去,用現成的 library 就會動了...

Ubuntu 20.04 推出

代號 Focal Fossa (focal) 的 Ubuntu 20.04 推出了,在官網上可以下載,另外也可以翻「FocalFossa/ReleaseNotes」這邊看看有什麼新功能。

ReleaseNotes 翻了一輪後看起來還好,主要是看到新版的 OpenSSH 支援了 U2F,可以找機會玩玩看,然後 ZFS 那邊有一些新玩具可以玩,其他的倒是還好...

另外裡面也有提到各家雲端平台都上架了,找一下對應的 image 應該是可以測試看看...

Python 2.7.18,官方提供的最後一個 2.7 的版本

本來 Python 2 官方的計畫是支援到 2020/01/01,但最後一個版本 Python 2.7.18 一直到剛剛 2020/04/20 才出。對照前一個版本 2.7.17,是 2019/10/19 的時候出的,這應該算是一個「經典」的落幕:「Python 2.7.18, the last release of Python 2」。

對於得用 Python 2 才能跑的專案 (目前手上應該就是 Trac),如果 Python 3 的版本再不出,再過個一年應該只能用 pyenv 撐場了...

在 EC2 上面跑 Lizzie + KataGo

我用 Packer 包了一個將 Lizzie (界面) + KataGo (引擎) 打包成 Amazon EC2 AMI 的設定:「packer-katago」。

這個組合應該是目前圍棋棋手最常拿來分析棋譜的工具,與之前常用的 Lizzie + Leela Zero 的差異在於 KataGo 可以分析勝率與目數,而 Leela Zero 則只能分析勝率。(參考之前寫的「用更少訓練時間的 KataGo」這篇)

早期的 KataGo 強度還沒有很強,一般還是會與 Leela Zero 交叉換著分析,但最近幾個版本的強度比之前好很多,目前看起來已經超過 Leela Zero 了 (可以參考 CGOS Whole Period Ratings for 19x19 Board 這邊列出來的排名),另外就 YouTube 上看起來,蠻多棋手應該都是改用 KataGo 了...

不過不管是 Leela Zero 還是 KataGo 都需要夠強的 GPU 運算,之前就算用 GTX 1080 Ti 也還是覺得不夠快,就丟到 AWS 上面用看看,順便練一下手,熟悉 Packer 怎麼用。

我是設計成用 IceWM + VNC,連進去後左下的選單裡面就會有 Lizzie 可以選:

第一次跑起來會比較久,我在 p3.2xlarge 的機器上大約要等個三四分鐘,然後就會出現數字了:

看了一下運算的速度還不錯,用 spot instance 開的話,成本上應該還可以接受 (剛剛的 p3.2xlarge 是 USD$0.918/hr)。

玩一下 Zipcall,走 WebRTC 與 P2P 架構的會議系統

這個連結在瀏覽器的 tab 上好幾天了,要寫這篇的時候試著找了一下當時是從哪個管道看到的來源,翻了一下看起來沒有在 Hacker News Daily 上面列出,但在 Hacker News 上面有找到討論串,不過最近沒有去從那邊翻連結...

Anyway,Zipcall 是使用 WebRTC 實做出來的會議系統,會議相關的流量會直接透過點對點的架構傳輸,不需要透過 server 交換。

由於架構上沒有 server 幫忙重新壓縮再轉給不同的使用者,也就 client 得自己處理,對硬體要求應該會比較高,另外對頻寬的要求也比較大。

另外他提到 latency 比較低這件事情,剛剛用兩隻 webcam 測試,一個掛到 vm guest 裡面,另外一個掛在 vm host 上面,測試下來很明顯可以感覺比起之前用 Zoom 高,可能要再研究到底是什麼原因,不確定跟 vm 有沒有關係,不過還在可以接受的範圍。

安全性與隱私性的實做方式也還得再看看是怎麼弄的,不過目前看起來應該可以先拿來玩玩...

Vim 的 virtualedit 與 GNU Make 內的 .PHONY

在「Writing a Book with Pandoc, Make, and Vim」這邊看到作者在講他怎麼用 Pandoc + GNU Make + Vim 寫書,不過我這邊看到兩個有趣的東西 (標題提到的那兩個),拉出來寫一下...

一個是 Vim 的 set virtualedit=all,可以不受限制的移動,等到實際編輯時再產生出對應需要的空白,這對於畫表格會方便不少:

另外一個是 GNU Make 的用法,平常我們都是在 .PHONY 裡指定實際上不會存在的 target:

.PHONY: clean
clean:
        rm -rf ./output

這邊作者提供的方式是產生一個叫做 phony 的 target,然後就不需要在 .PHONY 裡條列,而是各自在自己的 target 裡面引用 phony

.PHONY: phony
clean: phony
        rm -rf ./output

不過作者有提到效能問題:

Note that this trick can slow down huge Makefiles.

另外作者又提醒我 draw.io 這個好用的工具,之前用過幾次後就忘記了...

勸人從 Linux 跳到 FreeBSD 的戰文...

前幾天在 Facebook 上看到正妹朋友的貼文,然後在 Hacker News Daily 上也看到了:「Technical reasons to choose FreeBSD over GNU/Linux」。

標準的戰文 XDDD

在這篇講的是 FreeBSD 在技術上的優勢 (雖然我覺得很多不是優勢...),作者在一月的時候有另外兩篇在講 BSD (不只是 FreeBSD) 與 Linux,主題偏政治面 (包括了社群的運作方式) 與 license 之類的問題,也是戰文:「Why you should migrate everything from Linux to BSD」與「Why you should migrate everything from Linux to BSD - part 2」。

不過畢竟就是戰文,拿爆米花來吃就好,還是用的順手比較重要。當初 FreeBSD 的 issue tracking system 換掉以後,覺得太卡就抽手了,不然還蠻愛 Ports 的架構的...

AMD 平台的前面板與 USB...

Telegram 上看到這篇在講在 AMD 平台上遇到 USB 相容性的問題:

看了敘述與裡面連結提到的「Xperia XA2: Stuck on “Sending 'boot.img'”」與「Fastboot is getting stuck while trying to flash CWM onto Nexus 4」後,我就馬上想到我在換成 AMD 的平台後,遇到了一個感覺好像應該是有關的問題...

我遇到的問題是 YubiKey 在主機的前面板的四個 USB 接口都不會動 (抓的到,但是 browser 需要認證時 YubiKey 不會閃爍請使用者確認),而接到 USB 2.0 Hub 上面也不會動 (這邊的 Hub 是接到後面 USB 3.0 的孔),只有直接接到後面板的 USB 3.0 會動,所以我後來就買了一條 USB 3.0 的延長線,從後面的 USB 3.0 孔拉到桌上用...

昨天看到文章,為了確認這個情況,就到 PChome 24h 上找了一顆 USB 3.0 Hub,今天收到後接上 PC 測試,發現 YubiKey 就順利在登入時閃爍了,看起來之後在 AMD 平台上接 USB 的時候要注意一下,有狀況的時候要多測幾種不同的接法...