SQLite 3.37.0 以及 STRICT table 的設計

Hacker News 首頁上看到「SQLite Release 3.37.0 (sqlite.org)」,原文在「SQLite Release 3.37.0 On 2021-11-27」這邊。

這個版本引入了 STRICT Tables,先前在「SQLite 目前在規劃的 Strict Table,以及我從來不知道原來可以這樣惡搞...」這邊有提過。

官方給出來的範例是這樣,如果沒有要求 STRICT 的話,可以看到各種變化:

CREATE TABLE t1(a ANY);
INSERT INTO t1 VALUES('000123');
SELECT typeof(a), quote(a) FROM t1;
-- result: integer 123

加上 STRICT 後就會與「預期」的結果比較接近:

CREATE TABLE t1(a ANY) STRICT;
INSERT INTO t1 VALUES('000123');
SELECT typeof(a), quote(a) FROM t1;
-- result: text '000123'

對於希望 database 在處理資料嚴謹一點的人來說,應該是個不錯的新功能,但畢竟不是預設值,對於剛跨進來用的人應該還是有中獎機會 XD

把 YouTube 的 Dislike 數字弄回來

最近 YouTube 也在搞事,把 Dislike 的數字拔掉了,後來在 Greasy Fork 上面找了一下,看到有兩套方法可以把數字補回來。

第一套是「Return YouTube Dislike」這個方法,從程式碼裡面可以看到是透過 API 拉出來的:

function setState() {
  cLog('Fetching votes...');
 
  doXHR({
    method: "GET",
    responseType: "json",
    url:
      "https://return-youtube-dislike-api.azurewebsites.net/votes?videoId=" +
      getVideoId(),
    onload: function (xhr) {
      if (xhr != undefined) {
        const { dislikes, likes } = xhr.response;
        cLog(`Received count: ${dislikes}`);
        setDislikes(numberFormat(dislikes));
        createRateBar(likes, dislikes);
      }
    },
  });
}

這個 API 後面應該是接 Videos: getRating 拉資料出來,但畢竟不是直接打 YouTube API (比較麻煩,需要每個使用者自己申請 API token),這樣就有隱私的疑慮了...

另外一套是「Show Youtube Dislike Count」,看了裡面程式碼發現他是用 averageRating 反推回來:

if (likeCount >= 0) {
    const r = data.playerResponse.videoDetails.averageRating;
    const dislikeCount = Math.round(likeCount * (5 - r) / (r - 1));

    ShowDislikes(likeCount, dislikeCount);
}

不過作者有點偷懶,這邊在等待頁面生成單純用 100ms 等頁面出現,有時候還是會有 race condition (就是後面還是讀不到 XDDD),如果懶的大修的話可以改成 1000ms 混過去,降低一些機率:

while (!isLoaded) {
    await Sleep(100);
}

另外數字很大的時候會稍微不準,但也算夠用了,先暫時用這套來頂著了...

Amazon RDS 支援 readonly instance 當作 Multi AZ 的機器了

從來沒在用 RDS 的 Multi AZ,所以根本沒注意到居然沒這個功能:「New Multi-AZ deployment option for Amazon RDS for PostgreSQL and for MySQL; increased read capacity, lower and more consistent write transaction latency, and shorter failover time (Preview)」。

看起來 (加上印象中) 之前的 Multi AZ 是另外一台機器先開著但不能用:

In the case of an infrastructure failure, Amazon RDS performs an automatic failover to the standby, so that database operations resume as soon as the failover is complete.

現在則是開著的機器可以跑 readonly 模式:

The standby DB instances act as automatic failover targets and can also serve read traffic to increase throughput without needing to attach additional read replica DB instances.

這樣做除了省成本外,另外因為這些 instance 平常就有 query 的量,當真的遇到 failover 切換時,warmup 的時間也會短很多 (尤其是服務夠大的時候)。

不過有些限制,首先看起來只支援 Graviton2 (ARM-based) 的機種?

The readable standby option for Amazon RDS Multi-AZ deployments works with AWS Graviton2 R6gd and M6gd DB instances (with NVMe-based SSD instance storage) and Provisioned IOPS Database Storage.

然後是支援的區域:

The Preview is available in the US East (N. Virginia), US West (Oregon), and Europe (Ireland) regions.

以及夠新的版本,MySQL 8 與 PostgreSQL 13.4 才有提供:

Amazon RDS for MySQL supports the Multi-AZ readable standby option for MySQL version 8.0.26. Amazon RDS for PostgreSQL supports the Multi-AZ readable standby option for PostgreSQL version 13.4.

但看起來還不錯,畢竟這比較接近以前在地端機房時的作法...

來看 Intel + Varnish 的單機 500Gbps 的 PR 新聞稿

在「Varnish Software Achieves 500Gbps Throughput Per Server for UHD Video Content」這邊看到 PR 稿,由 IntelVarnish 合作,宣稱達到單機 500Gbps 的 throughput 了:

According to Varnish Software, the following were the outcomes of the test:

  • 509.7 Gbps live-linear throughput, using a dual-processor configuration
  • 487.2 Gbps video-on-demand throughput, using a dual-processor configuration

白皮書在「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」這頁可以用個資交換下載,不過用搜尋引擎找一下可以發現 Intel 那邊有放出 PDF (但不確定兩邊給的是不是同一份):「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」。

單 CPU 的伺服器是四個 100Gbps 界面接出來,雙 CPU 的伺服器是八個 (這邊 SUT 是 system under test 的縮寫):

These client systems were connected to the CDN servers using 100 GbE links through a switch; 4x100 GbE connections for the single-processor SUT, and 8x100 GbE for the dualprocessor SUT. Testing was done using Wrk, a widely recognized open-source HTTP(S) benchmarking tool.

不過如果實際看圖會發現伺服器是兩個 100Gbps (單 CPU) 與四個 100Gbps (雙 CPU),然後 wrk 也吃了兩個或是四個 100Gbps:

在白皮書最後面也有提到測試的配置,都是在 Ubuntu 20.04 上面跑,單 CPU 用的是兩張 Intel 的 100Gbps 網卡,雙 CPU 的用的是四張 Mellanox 的 100Gbps 網卡:

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Single processor SUT configuration was based on the Supermicro SMC 110P-WTR-TNR single socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by two 100 GbE Intel® Ethernet Network Adapters E810. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 8 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80 generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnishplus-6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Dual processor SUT configuration was based on the Supermicro SMC 22OU-TNR dual socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by four 100 GbE Mellanox MCX516A-CDAT adapters. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 12 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80- generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnish-plus6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

不過馬上就會滿頭問號,四張 100Gbps 是怎麼跑到 500Gbps 的頻寬...

這份 PR 馬上就讓人想到 Netflix 先前放出來的投影片 (先前有在「Netflix 在單機服務 400Gbps 的影音流量」這篇提到),在 Netflix 的投影片裡面有提到他們在 Intel 平台上面受限於記憶體的頻寬,整台機器只能跑到 230Gbps。

另外一種猜測是,如果 Intel 與 Varnish 宣稱的 500Gbps 是算 switch 上的總流量 (有這樣算的嗎,你是 Juniper 嗎...),那這邊的 500Gbps 換算回去差不多就是減半 (還很客氣的沒把 cache 沒中需要去 origin server 拉資料的流量扣掉),跟 Netflix 在 FreeBSD 上跑出來的結果差不多啊...

坐等反駁 XDDD

QOI 圖片無損壓縮演算法

Hacker News Daily 上看到「Lossless Image Compression in O(n) Time」這篇,作者丟出了一個圖片的無損壓縮演算法,壓縮與解壓縮的速度超快,但壓縮率又不輸 PNG 太多,在 Hacker News 上的討論也可以看一下:「QOI: Lossless Image Compression in O(n) Time (phoboslab.org)」。

裡面有提到在遊戲產業常用到的 stb_image.h

Yes, stb_image saved us all from the pains of dealing with libpng and is therefore used in countless games and apps. A while ago I aimed to do the same for video with pl_mpeg, with some success.

作者的簡介也可以看到他的主業也在遊戲這塊:

My name is Dominic Szablewski. I build games, experiment with JavaScript and occasionally tinker with low-level C.

圖片的無損壓縮與解壓縮算是遊戲創作者蠻常用到的功能,所以他想要看看這塊有沒有機會有更好的工具,於是他就用了四個很簡單的演算法幹完了 QOI (然後發現效果很讚):

  • A run of the previous pixel
  • An index into a previously seen pixel
  • The difference to the previous pixel
  • Full rgba values

其實從 Hacker News 的討論也可以看到這組演算法也常被拿出來在現代的壓縮演算法使用,所以雖然作者自稱不是 compression guy,但他用的演算法其實蠻專業的...

然後挑 single thread 主要是可以避免 threading 的複雜度以及 overhead,在「QOI Benchmark Results」這頁可以看到,無論是什麼類型的檔案,壓縮與解壓縮的速度都相當漂亮,而且壓縮率又沒有差 libpng 太多。

而且作者自己有提到,還沒用到 SIMD 指令集加速,這樣猜測應該還有不少空間...

使用 heredoc 語法的 Dockerfile

Simon Willison 這邊看到的,在 Dockerfile 裡面使用 heredoc 語法編 Docker image:「Introduction to heredocs in Dockerfiles」,引用的文章是「Introduction to heredocs in Dockerfiles」與「Introduction to heredocs in Dockerfiles」,七月的事情了。

heredoc 指的是可以讓開發者很方便使用多行結構,在 Dockerfile 這邊常見到的 pattern:

RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y ...

但這樣會產生出很多層 image,所以先前的 best practice 是:

RUN apt-get update && \
    apt-get upgrade -y && \
    apt-get install -y ...

而 heredoc 的導入簡化了不少事情,這應該有機會成為新的 best practice:

RUN <<EOF
apt-get update
apt-get upgrade -y
apt-get install -y ...
EOF

要注意的是,開頭要記得加上 #syntax 的宣告,用到 docker/dockerfile:1.3-labs 這組才能使用 heredoc:

# syntax=docker/dockerfile:1.3-labs

然後用 buildkit 去編,用新版的 Docker 已經包 buildkit v0.9.0 進去了:

DOCKER_BUILDKIT=1 docker build .

LLVM 的更換授權進展

Hacker News Daily 上看到「LLVM relicensing update & call for help」這篇,在講 LLVM 計畫從 UIUC licenseMIT license 授權轉成 Apache License 2.0 的進展,在 Hacker News 上的討論「LLVM relicensing update and call for help (llvm.org)」也可以翻一下。

目前的規劃是這樣:

文章開頭還是先花了一些篇幅解釋,這個計畫主要是要處理專利的問題,原先的 developer policy 對於專利的句子太粗糙,會授權過多的權力給 LLVM。這對於一般個人可能影響不大,但對於手上有一卡車專利的公司來說就不太願意了。

另外一個問題是 LLVM 遇到的問題,因為 runtime library 的部份是用 UIUC license + MIT license 授權,但主體是用 UIUC license 授權,這使得主體的程式碼不能隨意搬到 runtime library 裡面:

The run time libraries were dual licensed under the UIUC and MIT license; the rest of the code only under the UIUC license. Therefore, we could not easily move code to run time libraries from other parts. The reason run time libraries were dual licensed was to enable linking to run time library binaries without requiring attribution to LLVM.

因為這些目標,所以新的授權會是 Apache License 2.0 為主,裡面有設計還算合理的專利授權條件,另外大家也算熟悉,再來是針對 object code 以及 GPLv2 設計了例外條款:

As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License.

In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 ("Combined Software") and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.

在「Long tail of individuals and corporations without a relicensing agreement yet」這邊有目前還沒有同意重新授權的人以及團隊的資料,看起來不會是每個人都願意重新授權,到時候可能還得再挑出來重寫,但有些可以獨立出來的可能可以維持,畢竟 UIUC licesne 與 MIT license 都是 permissive license,只要放到另外一個目錄下,大家知道不是 Apache License 2.0 就還好...

在 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

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.