用 Perl 把 log 丟上 Slack

因為想在 Raspberry Pi 上面把一些 log 丟上 Slack,本來看到「Stream Any Log File to Slack Using curl」這篇,但發現裡面在把字串包進 JSON object 的方法太髒 (直接把 " 換成 '),另外一方面是 Slack 已經在宣導不要用舊版的 Incoming Webhooks,所以決定用其他方式來處理。

選擇 Perl 主要是因為有一陣子沒有用 Perl 寫東西了,倒不是什麼特別的原因 (如果考慮到 Raspberry Pi 上資源有限的話,應該用 C 或是 Rust 或是 Go,但我的 Raspberry Pi 還沒忙到這種程度...),所以決定用 Perl 來實做這個程式,把 log 檔案丟上 Slack:

這邊有些比較不太常見的選擇:

  • 不用 File::Tail 而反而是用 pipe 的方式取得 tail -F 的輸出,是因為 File::Tail 非常舊了 (2015),實做上沒有用到 inotify 類的界面監控檔案的變化,反而是系統的 tail 有做。
  • JSON::PP (pure perl 版本) 而不是 JSON 是因為 JSON::PP 在 Perl 5.14+ 後內建了,我沒有太在意效能,這也是上面放 use v5.14 的原因。
  • 這邊的 API 呼叫還是選擇了 WWW::Mechanize 是因為沒有內建的套件可以處理 HTTPS 連線 (可以參考 Perl core modules 這邊),既然要另外安裝,就裝個支援度比較完整的 libwww-mechanize-perl 來用。

然後查了一下 // 的用法在 Perl 5.10+ 就支援了,好早...

Amazon EC2 推出 VT1 Instance

看到 Amazon EC2 推出新機種 vt1,專門為影片壓縮而推出的 family type:「New – Amazon EC2 VT1 Instances for Live Multi-stream Video Transcoding」。

主要是透過 Alveo U30 Data Center Accelerator Card 這張卡加速,號稱比 GPU 機器還要省 30% 的費用 (CPU 的話可以到 60%):

These VT1 instances feature Xilinx® Alveo™ U30 media accelerator transcoding cards with accelerated H.264/AVC and H.265/HEVC codecs and provide up to 30% better price per stream compared to the latest GPU-based EC2 instances and up to 60% better price per stream compared to the latest CPU-based EC2 instances.

看規格支援 H.264H.265,不過看起來沒支援 royalty-free 的 VP9AV1...

另外這跟 AWS Elemental MediaConvert 以及 AWS Elemental Live 好像稍微有點打對台?另外專利的費用不知道怎麼算...

RabbitMQ 也進來搶 Streaming Engine 這塊市場了

RabbitMQ 要在 3.9 版推出 Streams (目前 3.9 還在 RC):「RabbitMQ Streams Overview」,在 Hacker News 上有一些討論可以看:「RabbitMQ Streams Overview (rabbitmq.com)」。

這樣 RabbitMQ 可以同時有 queue 與 stream 的能力,對於一些小專案應該會方便不少,算是打隔壁棚 Kafka 的痛點之一,弄一組 HA cluster 至少要三台 ZooKeeper 加上兩台 Broker,基礎建設還要有對應的 HA load balancer 機制,在 AWS 上可以拿 ELB 偷懶,如果是實體機房的話也許用 F5 擋,或是用 open source 的 Keepalived (或是老一點的 Heartbeat) + nginx

目前還不知道 scalability 的能耐,不過印象中在 queue 的單台 throughput 不差,如果沒有意外的話,streaming 的部份對小型專案應該夠用。

Apple 與 Amazon 都要推出無損版的音樂串流服務了

首先是 Apple 宣佈了無損的音樂串流服務,不另外加價:「Apple Music Launching Spatial Audio With Dolby Atmos and Lossless Audio in June at No Extra Cost」,官方新聞稿在「Apple Music announces Spatial Audio with Dolby Atmos; will bring Lossless Audio to entire catalog」。

再來是 Amazon 也宣佈跟上,本來就有提供無損的 Amazon Music HD 下放到 Amazon Music Unlimited 方案也可以聽了:「Amazon Music Matching Apple by Offering Hi-Fi Tier at No Extra Cost」。

這對 Spotify 的壓力應該不小,畢竟已經先宣佈會推出無損版,但卻反而先被競爭對手出招先行制定價錢了...

CentOS 將會變成 CentOS Stream

讓不少團隊要炸的消息,CentOS 將會被消滅變成 CentOS Stream:「CentOS Project shifts focus to CentOS Stream」與「CentOS Stream: Building an innovative future for enterprise Linux」。

很多團隊用 CentOS 的主要原因就是因為他基本上就是個 RHEL 重新打包的版本,一來更新速度沒有很快 (所以穩定不少,跑得好好的就不要動他最穩...),二來很多商用軟體都可以在支援 RHEL 時「順便」支援 CentOS。

再來是考慮到他有超級長的支援期,像是 2011 年推出的 CentOS 6 到上個月月底 (2020/11/30) 才終止支援,相較於 Ubuntu LTS 提供的五年來說長很多。

所以兩邊都有選擇的理由 (以及族群),一邊是追求穩定性,一邊是有新技術的需求。

不過 IBM 在 2018 年收購 Red Hat 後看起來對這件事情有很不一樣的看法:決定要收掉 CentOS,然後借屍還魂叫做 CentOS Stream,上面開始會有與 RHEL 不同的東西。

When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will be to migrate to CentOS Stream 8, which is a small delta from CentOS Linux 8, and has regular updates like traditional CentOS Linux releases.

所以接下來還有支援的兩個版本,分別是 2014 年出的 CentOS 7,將照原訂的 10 年計畫支援到 2024/06/30,以及 2019 年出的 CentOS 8,就只會支援到 2021/12/31 了。

翻了一下 Hacker News 上的討論,先不講幹聲一片的問題,看起來原來建立 CentOS 的 Gregory Kurtzer 決定出來再幹一次:「Original CentOS founder intends to create new fork of RHEL (rockylinux.org)」。

來看看後續社群會怎麼玩吧...

Debian 資助 PeerTube 發展

看到「Debian donation for Peertube development」這則消息,Debian 決定資助 10K 歐元提供給 PeerTube 發展。

不過更大的幫助應該是 PR 上的部份,這帶出來的曝光度以及「認可」的部份比 10K 歐元重要的多。

回到 Debian 決定資助的原因,是因為 DebConf20 需要一個非封閉式平台的直播架構,而 PeerTube 看起來很適合這個情境:

This year's iteration of the Debian annual conference, DebConf20, had to be held online, and while being a resounding success, it made clear to the project our need to have a permanent live streaming infrastructure for small events held by local Debian groups. As such, Peertube, a FLOSS video hosting platform, seems to be the perfect solution for us.

前幾天在「有風聲說司法部會把 Chrome 拆出 Google」這邊有提到 YouTube 很難取代的問題,這個算是其中的一個方向,試著在解決平台壟斷的問題...

棄用 Keybase (Zoom 買下 Keybase 的新聞)

前幾天的新聞,Zoom 的新聞稿:「Zoom Acquires Keybase and Announces Goal of Developing the Most Broadly Used Enterprise End-to-End Encryption Offering」,Keybase 的新聞稿:「Keybase joins Zoom」,看到後就把本來的服務刪一刪了...

這篇屬名由 Zoom 創辦人發出的公告,裡面多到讓人不知道怎麼吐槽的部份,我們就把唯一的粗體字拉出來討論好了:

We are excited to integrate Keybase’s team into the Zoom family to help us build end-to-end encryption that can reach current Zoom scalability.

先不講先前被戳破根本就不是 end-to-end encryption 的問題,影音上面因為 transcoding 的問題,如果要在 video stream 上做 end-to-end encryption 的話分成兩種方式可以做:

a) 一種是發送端直接產生出多個不同 bitrate 的 video stream,這種方式其他家都已經很熟悉了,缺點也很明顯,就是吃各種資源,包括發送端的壓縮能力與頻寬。

b) 另外一種方式是產生出可以疊加的 video stream,有點像是 progressive image 的方式,第一個 stream1 的畫質最低,第二個 stream2 則是「補強」第一個 stream1,這樣子可以降低資源的需求。

另外有想到 Homomorphic encryption 的方式,直接可以疊加加密後的 stream1 + stream2,不過 bitrate 應該不會降低,就算真的設計的出來應該也沒用...

如果是 a) 的方式,業界對於 key 的交換都已經解的還不錯了,但這個方式沒什麼競爭性 (因為其他家也都已經做完了)。

如果是 b) 的方式,很明顯該找的是 codec 的公司 (要做出可以疊加的 codec),而不是搞密碼學的公司。

回到原來的問題,現有的團隊有 2500 人,裡面的技術團隊沒辦法搞定 end-to-end encryption,ok 沒關係,那現在的 CTO Brendan Ittelson 應該可以建一個團隊吧?所以我翻了一下他的 LinkedIn 看了一下他的經歷,對不起我錯了,我瞬間不知道怎麼寫下去了,我豆頁痛...

Kafka 拔掉 ZooKeeper 的計畫

目前 Kafka cluster 還是會需要透過 ZooKeeper 處理不少資料,但眾所皆知的,ZooKeeper 實在是不好維護,所以 Kafka 官方從好幾年前就一直在想辦法移除對 ZooKeeper 的相依性。

這篇算是其中一塊:「Kafka Needs No Keeper」。

真的自己架過 Kafka cluster 就會知道其中的 ZooKeeper 很不好維護,尤其是 Apache 官方版本的軟體與文件常常脫勾,設定起來就很痛苦。所以一般都會用 Confluent 出的包裝,裡面的 ZooKeeper 軟體與 Confluent 自己寫的文件至少都被測過,不太會遇到官方文件與軟體之間搭不上的問題。

另外一個常見的痛點是,因為 Kafka 推動拔掉 ZooKeeper 的計畫推很久了 (好幾年了),但進展不快,所以有時候會發現在 command line 下,有些指令會把 API endpoint 指到 ZooKeeper 伺服器上,但有些指令卻又指到 Kafka broker 上,這點一直在邏輯上困擾很久,直到看到官方的拔除計畫 (但又不快) 才理解為什麼這麼不一致...

給需要的人參考,當初在架設 Kafka cluster 時寫下來的筆記:「Confluent」。

擋 Live 與 Podcast 內廣告的工具

看到「An adblocker for live radio streams and podcasts. Machine learning meets Shazam.」這個專案,這個把 machine learning 用到「正途」上了啊...

不過畢竟是比較複雜的演算法,會吃不少 CPU 資源:

On a regular laptop CPU and with the Python time-frequency analyser, computations run at 5-10X for files and at 10-20% usage for live stream.

不過看用法還是偏向 library 性質,如果要大力推廣可能還是需要有其他人包個更好的界面...