在 command line 下生出全灰的圖片

因為需要一張 1920x1080 全灰色的圖片,翻了一下 DuckDuckGo 找到這篇:「Linux create Image pixel by pixel in command line」。

裡面抓重點,主要的想法是 PPM 格式 (可以參考「Netpbm」這個條目),然後找到「PPM Format Specification」這份文件。

主要就是用 P3 模式下去產生檔案:

repeat 2073600 echo '127 127 127' >> grey.ppm

然後開頭的地方修一下,加上 P3、長寬資訊以及最大的值:

P3
1920 1080
255

接著就用 ImageMagick 轉檔:

convert grey.ppm grey.png

然後用 viewer 看一下,確認沒問題就收工了...

把 Whoogle 改跑在 Raspberry Pi 上面

本來是把 Whoogle 跑在固定 IP 的機器上面,後來發現一下就被擋了,改用 Tor 跑也沒用 (exit node 的 IP reputation 應該更差),花了些時間搬到 Raspberry Pi 上面跑,改用浮動 IP 來跑。

首先是 Docker 跑不起來的問題,這主要是 Raspberry Pi 第一代的 CPU 指令集似乎跟主流的 armhf 不同?不確定... 但最後是直接上 pipx 解決。

跑起來以後發現 IPv6 的 reputation 也很差,幾乎是一定會被擋 (在『繞過 Web 上「防機器人」機制的資料』這篇有提到),所以乾脆把整台機器的 IPv6 network 都關掉,強迫讓他走 IPv4 network,然後再定時重新撥 PPPoE 去換 IP...

不過目前是跑在 Raspberry Pi 第一代上面,速度真的好慢... 看之後有沒有機會換另外的板子 :o

歐盟對 Google 的 24.2 億歐元的罰款確定

從「Google loses challenge against EU antitrust ruling, $2.8-bln fine」這邊看到的,新聞的標題寫的是換算後的美金。

新聞裡提到歐盟主要有三個主題在跟 Google 訴訟,這次確定的是利用搜尋引擎偏好自家的購物比較服務,產生不公平競爭:

Competition Commissioner Margrethe Vestager fined the world's most popular internet search engine in 2017 over the use of its own price comparison shopping service to gain an unfair advantage over smaller European rivals.

另外兩個還在進行的是 AndroidAdSense

The company could face defeats in appeals against the other two rulings involving its Android mobile operating system and AdSense advertising service, where the EU has stronger arguments, antitrust specialists say.

應該是還有個 YouTube 才對,不過印象中主要是版權相關的問題,跟 antitrust 這邊的關係好像少了一些...

法院認為 Apple 必須在 12 月 9 日前開放行動平台上的第三方支付

大標題是「Judge orders Apple to allow external payment options for App Store by December 9th, denying stay」,小標題是「And Apple announces it will appeal」。

本來 Apple 想要繼續拖延,但法院直接打槍,然後 Apple 決定要再上訴到第九巡迴庭,基本上我們就是在旁邊坐著等看戲...

另外前陣子 Google 宣佈在南韓會開放其他付款機制 (參考「Google 在南韓開放 app 裡面使用其他付款機制了」),就沒看到 Apple 這邊的動作,找了一下新聞只看到 Apple 在南韓的頭決定不幹了:「Apple's top exec in South Korea departs amid dispute over App Store」,也許之後再找看看...

莫斯科大學的學生自己在宿舍架設宿舍網路的歷史故事 (2002~2013)

Lobster Daily 看到「Moscow state university network built by students」這篇,不過 Hacker News 上的討論多一點:「“Illegal” Moscow state university network built by students (2002-2013) (medium.com/pv.safronov)」。

莫斯科大學宿舍網路的故事,發生在 2002 年到 2013 年之間:

They had built a network on their own, which provided students Internet connection from 2002 till 2013 (when the administration effectively legalized this network).

算是老人懷舊的故事,不過看起來作者留下了大量的照片看起來就更有趣了...

查了一下資料,交大應該是 1993 年 1992 年就開始有宿舍網路了 (可能更早?),而且是校方用同軸電纜 (Coaxial cable) 拉的,後來經過更新也換到雙絞線了 (UTP,Twisted pair),現在應該是 1Gbps 的頻寬,不過不知道建築物之間是怎麼放的了。(大概還是光纖,依照集縮比應該是跑 10Gbps 的協定,S 系列的那幾個可能距離都太短,大概是 L 的吧,不知道是幾對...)

首先這是個橫跨整個主建築物的網路建制,分成五個大區塊:

Google Maps 拉一下距離,光是兩端的直線距離就快要 0.5km 了,應該沒找錯建築物,看起來是這棟沒錯...

從作者提供的圖片也可以看出來建築物本身超大:

回到網路的部份,本來是用 10Mbps 的 Hub 接 (算是 2002 年比較好取得的網路設備?),但因為是 Hub 所以頻寬使用率不高 (Collision domain 的效率下降),換成 Switch 後降低了很多不必要的流量:

In the beginning, there were only 10 Mbps hubs available. They were extremely slow because the packet arriving at one port was mirrored to all other ports, flooding the network with unnecessary traffic. Later they were replaced by L2 switches, that are smart enough to choose the destination port for the packet.

但宿舍網路是有競爭對手的,兩邊常常破壞對方 XDDD

Having two competing networks was a cherry on the top of it. They were cutting each other’s cables, executing DDoS attacks, stealing equipment, etc.

然後是拉光纖對接幾個主要的區塊,以上面剛剛拉出來的數字來看,應該是因為雙絞線 (UTP,Twisted pair) 的 100 公尺長度限制,所以這部份必須透過光纖:

To connect this router to the other parts of the network, we laid fiber cables through secret passages in the walls, ceilings, floors, and ventilation shafts.

然後用 Switch 再拉到每個房間 (所謂的 Last mile):

然後外部就沒在怕你的拉:

還包括了把 UTP 的八芯線分開用的方法,這邊提到了 100Mbps 應該是升級上去了:

Most of the time, we managed to reduce the number of cables coming out of the window down to ~15. We could do this because of a simple trick: the regular ethernet cable (Cat 5e) has 8 wires. And to transmit 100 Mbps, you need just 4 of them. All 8 wires are required only for a 1 Gbps connection. So using a single cable, you can connect 2 clients who live close to each other. We always tried to do that if possible because the hole can’t fit so many cables.

往後拉一點的樣子:

後面講到很多故事以及常見的 trouble shooting 問題,現在的網路設備能支援的架構好太多,應該都有比較好的解法了...

Fork 自微軟的 Pyjion 專案的 Python 3.10 + JIT 方案

Hacker News 上看到「Pyjion – A Python JIT Compiler (trypyjion.com)」這個專案,也是一個想要透過 JIT 加速 Python 的專案:

Pyjion is a drop-in JIT Compiler for Python 3.10. It can be pip installed into a CPython 3.10 installation on Linux, Mac OS X, or Windows.

看了一下是從微軟的 Pyjion 專案 fork 出來的,原來的專案最後一次 commit 是一年前,而且專案也已經標示為 archived (read-only mode),但有留下轉移的說明,也就是上面提到的專案:

Development has moved to https://github.com/tonybaloney/Pyjion

可以看到大部分的效能都已經進入改善階段 (很多導入 JIT 的專案在初期時會先變慢):

跟其他的 JIT 方案相比,Pyjion 的目標是高度相容現有 Python 的程式,包括各種 extension,這點的確是在用 PyPy 這些軟體時的痛點沒錯...

看起來透過 pip 裝好後就可以直接 import 進來用,後續就會生效:

import pyjion; pyjion.enable()

另外提一下,翻 Hacker News 留言的時候翻到這個害我笑出來,有夠新 XD

zatarc 3 days ago | unvote | prev | next [–]

Pyjion requires: CPython 3.10 and .NET 6

.NET 6 Release: 19 hours ago (https://github.com/dotnet/core/blob/main/release-notes/6.0/6...)

... ok.

用 PostgreSQL 的 int4range 與 GiST

發現自己根本還不熟悉 PostgreSQL 的特性,寫一下記錄起來。

產品上常常會有 coupon 與 voucher 之類的設計,這時候通常都會設定 coupon 或 voucher 的有效期間,在 MySQL 的環境下可能會這樣設計:

CREATE TABLE coupon (
  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  code VARCHAR(255) NOT NULL,
  started_at INT UNSIGNED NOT NULL,
  ended_at INT UNSIGNED NOT NULL
);

另外是設計 index 的部份,在產品推出夠久後,通常是過期的 coupon 或 voucher 會比目前還有效的多,而還沒生效的 coupon 與 voucher 通常都不多,所以會設計成對 ended_at 放一組 B-tree index:

CREATE INDEX ON t1 (ended_at);

這個設計不算差,不過用了一些假設。

如果不想要用這些假設,可以改用 Spatial 的資料型態去模擬並且加上 index (使用到 LineString Class),這樣就直接對 a < x < b 這類查詢更有效率,不過缺點就是可讀性會比較差。

在 PostgreSQL 這邊就有更清晰的資料結構來處理這些事情,主要是有一般性的 int4rangeint8range 以及時間類的 tsrangetstzrangedaterange (參考「Range Types」這邊有更多資料型態),所以會變成:

CREATE TABLE coupon (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  code VARCHAR NOT NULL,
  active_at INT4RANGE NOT NULL
);

然後用 GIST 建立 index:

CREATE INDEX ON t1 USING GIST(active_at);

後續的 query 語法就用 <@ 的語法:

SELECT COUNT(*) FROM coupon WHERE 10000 <@ active_at;

塞了 10M 筆資料後的 table 可以看到本來需要的時間是:

Time: 779.542 ms

變成:

Time: 5.510 ms

不過缺點就是 SQLite 沒支援這些資料型態,對於 test case 就一定得跑個 PostgreSQL 起來測...

PostgreSQL 14 支援的 LZ4 壓縮

Hacker News 上看到 PostgreSQL 14 新支援的 LZ4 壓縮:「The LZ4 introduced in PostgreSQL 14 provides faster compression (fastware.com)」,在討論裡面反而有提到可以用 ZFS 的壓縮,這樣所有的資料 (包括 index) 都可以被壓縮:

If you are using ZFS, I strongly recommend using LZ4 or ZSTD compression with PostgreSQL. Performance is still awesome. On average I get 2x compressionratio with LZ4 and 4x with ZSTD.

With this, you are compressing everything, not just columns. And ZFS has dynamic block sizes which works really great together with compression. For example a 8kb PostgreSQL page, may be stored as a 1kb compressed block on disk.

而且通常開了壓縮後,整機的效率都會比較好。主要是因為資料庫的資料夠大時 (超過記憶體大小) 通常效能會先卡在 Disk I/O 的部份,這時候 CPU 會太閒;如果挑個輕量的壓縮演算法的話,雖然 CPU 使用率會拉高一些,但會大幅降低 Disk I/O 的量,在很多情況下就會提昇效能...

上面提到主要是 OLTP 的情況下,如果是在 OLAP 的場景下就更明顯了,基本上大家都是預設開著壓縮在處理所有資料。

另外在很多 RPC 類的系統也有類似的現象,資料傳輸量已經太大會超過 Network I/O 可以提供的量,這時候導入一些輕量的壓縮演算法就能大幅提昇系統效能。

以前有讀到一些壓縮演算法的比較,像是先前有翻到的「Evaluating Database Compression Methods: Update」,針對演算法的部份分析,裡面最後一張圖可以看到比較:

從比較圖可以穿來 Snappy 後來被 LZ4 淘汰掉,主要就是 LZ4 的壓縮率比較好,壓與解的速度又比較快,沒有理由繼續 Snappy。

另外 Zstandard 也逐步在淘汰 gzipzlib 類的壓縮,不過畢竟 gzip 與 zlib 的歷史真的太久,這邊淘汰的速度不快...

生一個 static 版本的 ffmpeg

目前有丟出來的 FFmpeg 執行包都會因為軟體授權不相容的問題,沒辦法把想要的東西都包進去 (或者無視授權丟出來 XD),但反正看一看沒看到適合的,所以弄了一天包了一包出來。另外也是因為同樣理由,這邊也只能提供步驟讓大家自己編...

我的主力放在 AV1VP9 的支援上,步驟就寫在「FFmpeg」這邊了,裡面是先開了一個 Docker container 再去裝環境,接著再把會用到的 source code 用 git clone 拉下來再固定版本,所以應該是不會有太大的意外。

另外可以看到 libfdk-aac 與 libx264 兩包我就直接拉系統的套件來包,主要是查了一下版本還算堪用,而且也不是主力要處理的東西,就不想要再自己拉下來編了。

這邊就是整理一下感想...

首先是 Rust 一直在推新功能,然後各家的軟體也幾乎就是馬上跳進去用這些新功能,所以只能用 rustup 跟到最新版的 Rustc 去編 rav1e

然後 x265 搞不定 static compile 的問題,卡在沒有 libgcc_s.a 可以用,如果還要搞 GCC 的話就太累了...

這樣在 AV1 與 VP9 的支援度就比較完整了,另外內建 libvmaf 也可以拿來分析...

在非 4K 的螢幕上跑 HiDPI

前幾天看到 BetterDummy 這個專案,作者在 M1 上面外接 24" 1440p 的螢幕,但沒辦法啟用 HiDPI,於是就寫了一個軟體來解:

M1 macs tend to have issues with custom resolutions. Notoriously they don't allow sub-4K resolution displays to have HiDPI ("Retina") resolutions even though (for example) a 24" QHD 1440p display would greatly benefit from having an 1920x1080 HiDPI "Retina" mode.

在這之前的解法都有些麻煩,一種是買個 dummy dongle 去騙 macOS,另外是用 mirror 的方式使用:

To fix this issue, some resort to buying a 4K HDMI dummy dongle to fool macOS into thinking that a 4K display is connected and then mirror the contents of this dummy display to their actual monitor in order to have HiDPI resolutions available. Others use the built in screens of their MacBooks to mirror to the external display. These approaches have obvious drawbacks and cannot solve all problems.

作者提供的軟體可以先建立 Dummy Monitor,然後再透過 mirror 掛到實際螢幕上:

不確定用起來如何,但如果之後有需要的話好像可以測試看看...