CSS 的 feature detection:@support

在「Conditional CSS」這篇裡面在講很多 CSS 條件過濾的方式,裡面看到有 @support 這個規格,可以透過 feature detection 的方式來過濾:「CSS at-rule: @supports: selector()」。

文章作者給的範例是這樣:

@supports selector(:has(p)) {
  .card-thumb {
    aspect-ratio: 1;
  }
}

在瀏覽器支援 :has(p) 的情況下才指定裡面的 CSS。

翻了一下 @support 在各家瀏覽器上實做的情況:在 Firefox 上是 69 開始支援,推出的日期是 2019/09/03。在 Chrome 上是 83 開始支援,推出的日期是 2020/05/19。在 Safari 上是 14.1 開始支援 (對應到 iOS 版本是 14.5),推出的日期是 2021/04/26。

從日期可以看出來算是比較新的功能,但主要幾個大的瀏覽器都支援了。

這個讓我想起來早期利用各家瀏覽器的 bug 產生出的各種 hack:「Browser Specific Hacks」。

Vultr 更新流量計算方式

一時間沒找到在哪邊看到的,但的確是漏掉這個消息,早上看到去翻才注意到的... Vultr 在去年 11 月底宣佈更新流量的計算方式:「Vultr Announces Reduced Bandwidth Pricing, 2 TB of Free Monthly Egress, Free Ingress, and Global Pooling」。

這波費用的更新算是跟上另外兩家 (LinodeDigitalOcean) 的算法了,先前 Vultr 的算法就很古老 XD

第一個是 inbound traffic 不算錢了 (總算):

Data ingress will now be free.

再來是 traffic pool 的概念,現在每個帳號的流量會統一計算,而非每台機器自己計算:

All customers will receive global account-level pooling of transfer across all instances and locations.

然後是每個帳號都提供 2TB 的 free outbound traffic,這點有點放送的感覺:

Every Vultr customer will now receive two terabytes (2 TB) of free outbound data transfer every month, in addition to the transfer included with each subscription.

最後是超量的部份收費也簡化了,不管什麼地區都是 $0.01/GB:

Vultr will now offer a reduced, single worldwide egress overage rate of only $0.01 per GB.

最後這點有個值得操作的點:依照他的收費標準,超量 1TB 的流量需要付 $10 的費用,但你可以多租一台 $5/mo 的機器,這個方式提供了 1TB 的流量到 traffic pool 裡面。

YAML 常見的問題

Hacker News Daily 上看到「The yaml document from hell」這篇在抱怨 YAML 的問題,而 Hacker News 上對應的討論在「The Yaml document from hell (ruudvanasseldonk.com)」這邊。

翻了一下我之前也有提到好幾次不同來源的抱怨:「YAML 的地雷 (2014)」、「YAML 的痛點 (2019)」、「YAML 的問題 (挪威問題) (2021)」。

這篇提到的東西還是類似之前提到的,但整理的蠻不錯的?他給了一個看起來蠻正常的 YAML,然後裡面全部都是地雷,你可以看他的說明知道是什麼問題。

不過他提出來的問題都是可以加上 double quote 來避開,但把這個方式當作 common practice 用 YAML 會變得很痛苦。

不過市場上還沒有能取代的東西,只能先繼續邊用邊罵了,看了一下 Hacker News 上的留言,簡單一點的東西 (只是要放幾個值的) 大家都覺得 INI 還可以拿來用用...

電梯裡取消樓層的作法

Hacker News 首頁上看到這篇:「Undo codes for Japanese elevator floor buttons (soranews24.com)」,原文是 2017 的文章,在講日本電梯取消樓層的方式:「The secret undo codes for Japanese elevator floor buttons」。

裡面提到的是這則推:

常見的大概就這幾三方法取消:

  • 長按按錯的樓層。
  • 連按兩次按錯的樓層。
  • 連按五次按錯的樓層。(富士)

台灣因為蠻多電梯也是同樣牌子的,也都可以這樣取消...

用 TeX 寫數學公式時常見的錯誤與解法

Hacker News 上看到「The Art of LaTeX: Common mistakes and advice for typesetting proofs (fanpu.io)」,原文在「The Art of LaTeX: Common Mistakes, and Advice for Typesetting Beautiful, Delightful Proofs」這,在講用 TeX 寫數學公式時常見的錯誤 (以及正確的寫法)。

裡面給了蠻多還蠻實用的提醒,像是第一點提出來的這兩個差異:

以及:

上面是用最單純的 {( 寫的,要達到下面比較正確的效果,不應該用 \bigl 這種直接指定括弧大小的用法,而是用 \left( 這種告訴 TeX 排版引擎這邊的意義,然後算出需要拿多大的括弧出來用。

畢竟 TeX 是 Knuth 老人家弄出來的東西,你會看到很多設計是需要給 TeX 排版引擎正確的定義或是資訊,剩下的他就會幫你處理...

KataGo 1.12.0 與 UEC 杯用的 model:b18c384nbt-uec.bin.gz

剛剛看到 KataGo 出了 1.12.0,同時也放出了在 2022 年十一月 UEC 比賽時用的 model:「New Neural Net Architecture!」。

1.12.0 比較特別的新的類神經網路架構:

This version of KataGo adds support for a new and improved neural net architecture!

這個新的架構以及其他的改善讓訓練的速度改善:

The new neural nets use a new nested residual bottleneck structure, along with other major improvements in training. They train faster than KataGo's old nets and learn more effectively.

另外一個是他把 UEC 比賽時用的 model 放出來了,很特別的是採用 b18c384,而 KataGo Distributed Training 這邊目前主要是 b40c256 與 b60c320,看起來是為了比賽而一次性訓練出來的。

依照他的說法這個 b18c384 版本跟目前訓練網站上的 b60c320 有差不多強度,但計算速度會比 b60c320 快不少,甚至在一些機器上會跟 b40c256 差不多快:

Attached to this release is a one-off net b18c384nbt-uec.bin.gz that was trained for a tournament in 2022, which should be of similar strength to the 60-block nets on http://katagotraining.org/, but on many machines will run much faster, on some machines between 40-block and 60-block speed, but on some machines even as fast as or faster than 40-block.

另外一個大改變是他把訓練工具從 TensowFlow 跳槽到 PyTorch

The training code has been all rewritten to use pytorch instead of tensorflow.

在 release note 裡沒有提到原因,但這個頗讓人好奇的...

fp32、fp16 與 bf16

nanoGPT 這個專案下面看到 bf16 這個浮點格式:(這段在新版的 README.md 被改寫了)

Currently fp16 is much faster than bf16. Potentially revert back to using fp16 and re-introduce the gradient scaler?

翻了一下 bf16,是由 Google 的團隊所提出來的想法,主打是與 fp32 相同的表示範圍,但是犧牲精度,這樣一來既有使用 fp32 的程式很有機會可以直接換成 bf16 降低計算量 & 提昇效率 (也就是 drop-in replacement):

然後同一頁也看到各家自己推出不同的格式,這邊看起來比較像是市場競爭的關係...

Debian 移除 Python 2 套件

Hacker News 首頁上看到 Debian 移除 Python 2 的消息:「Python 2 removed from Debian (debian.org)」,對應的 ticket 在這邊:「#1027108 - RM: python2.7 -- RoQA; Obsolete - Debian Bug report logs」。

Python 2 從 2015 年喊 EoL 喊很久,終於在 2020/04/20 發行最後一版 Python 2.7.18

大多數的套件應該都有 Python 3 的支援了,有需要的人 (像是還是沒支援 Python 3 的 Trac) 可以透過 pyenv 建立 Python 2 的環境出來跑,或是丟進 Docker 裡面跑。

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

資料庫在 2022 年的發展

Hacker News 上看到這篇對 2022 年資料庫發展的回顧文章,可以補一些沒看到的新聞與發展:「Databases in 2022: A Year in Review」,作者 Andy PavloOtterTune 的創辦人,有些他的想法會有些偏見,就當作一方之言來看就好。另外在 Hacker News 上的討論則是冒出一堆創辦人出來替自己公司的產品介紹一番:「Databases in 2022: A Year in Review (ottertune.com)」。

首先是他提到的 ClickHouse,我是 2022 年才開始關注,而且發現很不賴。查了一下維基百科,在 2021 年十月的時候搞了 round B $250m,估值 $2b:

On October 28, 2021 the company received Series B funding totaling $250 million at an valuation of $2 billion from Coatue Management, Altimeter Capital, and other investors.

另外是 Meta 弄出來的 Velox,直接看官網上面的圖可以看到,他試著把 Database、PrestoSpark 的 engine/worker 層抽換掉:

GitHub 的頁面說明上也可以看出來,Velox 是提供很多已經最佳化過的界面 (包括了 Type、Vector、Expression Eval、Function Packages、Operators、I/O、Network Serializers 與 Resource Management) 讓 engine/worker 直接使用,避免了自己的實做沒有最佳化:

Velox is a C++ database acceleration library which provides reusable, extensible, and high-performance data processing components.

In common usage scenarios, Velox takes a fully optimized query plan as input and performs the described computation. Considering Velox does not provide a SQL parser, a dataframe layer, or a query optimizer, it is usually not meant to be used directly by end-users; rather, it is mostly used by developers integrating and optimizing their compute engines.

其他的消息就看過去有個印象...