Twitter 砍免費 API 的時程延到 2/13

先前在「Twitter 宣佈要廢掉免費的 API 權限」這邊有提到在 2/9 要廢掉 API free tier 的事情延期了,延到 2/13:

據說跟老闆很在意 Super Bowl,然後丟了內部信件出來有關:

本來想說今天會爛掉,剛好可以來弄弄,看起來可以拖延到週末了...

Twitter 宣佈要廢掉免費的 API 權限

昨天下午的時候看到這則官方在 Twitter 上提到的消息,要廢掉 free tier 的 API access:

但這邊提到的 paid basic tier 的價錢還沒看到公告。以「API Pricing - It’s very dark out here」這邊看到的價格,目前的 premium plan 超級貴:

這下看起來是真的得搬了,目前有好幾隻程式在上面跑 :o

CPU Core 之間溝通的時間成本

Hacker News 上看到「Measuring CPU core-to-core latency (github.com/nviennot)」這篇,專案在「Measuring CPU core-to-core latency」這裡,看起來是個有趣的研究,測試許多不同 CPU 內,跨 core 之間溝通的時間花費。

依照專案的說明,測試的方式是利用 cache coherence 來來量測:

We measure the latency it takes for a CPU to send a message to another CPU via its cache coherence protocol.

By pinning two threads on two different CPU cores, we can get them to do a bunch of compare-exchange operation, and measure the latency.

裡面已經測了很多不同的 CPU,然後可以看到一些有趣的結果。

像是第一張圖片的「Intel Core i9-12900K @ 8+8 Cores (Alder Lake, 12th gen) 2021-Q4」這組,大家還蠻好奇 CPU #8 到底是怎麼一回事,跨 core 溝通的 latency 特別低,還特別找了 CPU 的 die 圖片看看:

另外一個是 AWS 上的 c6a.metal,機種是「AMD EPYC 7R13 @ 48 Cores (Milan, 3rd gen) 2021-Q1」,可以看到被分成了六個區塊:

接下來在 ARM 平台,在更多 CPU core 的 c7g.16xlarge 上,機種「AWS Graviton3 @ 64 Cores (Arm Neoverse, 3rd gen) 2021-Q4」,會看到更多不平均的現象:

早一點的 c6gd.metal 雖然也還是 ARM 的 64 cores 機種「AWS Graviton2 @ 64 Cores (Arm Neoverse, 2nd gen) 2020-Q1」,但可以看到很不一樣的 latency pattern:

大致上可以感覺到當 core 數愈多就會有很多技術上的瓶頸,導致不同 core 之間的溝通成本不一樣... 這個感覺跟當初學到 NUMA 的情況有點像。

白宮宣佈由政府資助的研究,都必須馬上公開

一樣是 Hacker News 上看到的:「Guidance to make federally funded research freely available without delay (whitehouse.gov)」,白宮的公告在「OSTP Issues Guidance to Make Federally Funded Research Freely Available Without Delay」這邊。

開頭有重點,不得限制以及收費。所以 paywall 是一定不行,另外要註冊才能看也算是一種限制,應該也會被這次的政策要求改善:

In a memorandum to federal departments and agencies, Dr. Alondra Nelson, the head of OSTP, delivered guidance for agencies to update their public access policies as soon as possible to make publications and research funded by taxpayers publicly accessible, without an embargo or cost.

時間表的部份,短期是 2023 年中更新 policy,並且在 2025 年年底前全部施行:

In the short-term, agencies will work with OSTP to update their public access and data sharing plans by mid-2023. OSTP expects all agencies to have updated public access policies fully implemented by the end of 2025.

這次的算政府方面的政策,至少這些論文會有地方可以公開下載。

找了一下之前寫下來跟 open access 有關的消息,從學校方面給壓力的也不少,不過我記錄下來的主要都是跟 Elsevier 的中止合約:

看起來不同角度都有一些推進...

觀察誰在存取剪貼簿的工具 (X11 下)

兩個月前在 Hacker News 上看到的討論,有人想要知道誰在 X11 下存取剪貼簿:「Who keeps an eye on clipboard access? (ovalerio.net)」,原文在「Who keeps an eye on clipboard access?」這邊,作者用 Python 寫的程式則是在「clipboard-watcher」這邊。

馬上有想到 iOS 在 2020 年推出的機制:「iOS 14 clipboard notifications are annoying, but developer adoption of a new API will improve the experience」。

不過在 X11 上跑起來會發現冒出來的資訊量有點大,像是在瀏覽器操作 WordPress 寫文章時剪剪貼貼的時候就會狂噴,如果可以提供程式的白名單的話就更好了,畢竟是我直接把 clipboard API 裡讀取的功能直接拔掉 (但網站還是可以寫進去就是了),對我來說不會在意 browser 寫進去的情況:

另外程式有時候會卡住 (尤其是遇到圖片的剪輯時),算是 bug 吧...

然後 Hacker News 的討論串裡面有人提到一個有趣的設計,他希望限制那些不在焦點上面的程式去碰 clipboard:

By far the worst offense I've seen in clipboard privacy on the Linux desktop is RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines, even when they are not focused, with no indication that it's happening, and with no GUI option to turn it off. This is at odds with the common practice of running untrusted code in virtual machines.

這個想法好像不賴,理論上 clipboard 應該是在有互動的時候才會碰到的東西...

限制流量的方式 (rate limit)

Lobsters Daily 上看到這篇 2017 年的文章,Figma 的工程師講怎麼做 rate limit:「An alternative approach to rate limiting」,只要大一點的站台就會遇到 spammer 之類的攻擊,就會希望實做自動化的機制擋住 spammer。

文章裡面提到了三種方式,第一種 (類) 提到了經典的 Token bucketLeaky bucket,這邊文章提供的演算法是讓每個使用者都會有一筆資料紀錄在 Redis 裡面 (這邊的用法可以抽換換成 Memcached),裡面記錄了最後一次的 access time 以及還剩下多少 token 可以用,接下來就可以照時間計算 token 的補充與消耗:

但這個演算法的缺點是 race condition,需要另外設計一些機制確保操作的 atomic:

不過大多數的實做就算不管 atomic 也還行 OK,只是會比較不精確一點。

第二個方法他叫做 Fixed window counters,這個方法把時間切齊為單位 (像是 60 秒為一個 window),所以可以把起點的時間也放到 key 裡面,然後 value 就是數量:

這個作法的好處就是簡單,而且 Redis 與 Memcached 都有提供 atomic 的 +1 操作。但缺點是可能會發生兩倍以上的 request,像是 5 reqs/min 的限制有可能會有連續的一分鐘內達到 10 reqs/min:

不過我覺得就 antispam 來說算是夠用了,當年 (大概是 2007 或是 2008 年?) 在 PIXNET 時用 C 寫 Apache module 就是把資料丟到 Memcached 裡面就是這樣實做的,然後每次學術網路的實驗室跑來掃站的就會自動被擋 XDDD

第三種方式他們稱作 Sliding window log,就是把每個 request 的 timestamp 都存起來,這個部份用 Redis 的資料結構會比用 Memcached 方便一些:

這個方式在控制上更精確,不過空間成本上就高很多... 這樣算是把常見的實做方式都提到了。

MySQL 在不同種類 EBS 上的效能

Percona 的人寫了一篇關於 MySQL 跑在 AWS 上不同種類 EBS 的效能差異:「Performance of Various EBS Storage Types in AWS」,不過這篇的描述部份不是很專業,重點是直接看測試資料建立自己的理解。

他的方法是在 AWS 上建立了相同參數的 gp2gp3io1io2 空間,都是 1TB 與 3000 IOPS,但他提到這應該會一樣:

So, all the volumes are 1TB with 3000 iops, so in theory, they are the same.

但這在「Amazon EBS volume types」文件上其實都有提過了,先不管 durability 的部份,光是與效能有關的規格就不一樣了。

在 gp2 的部份直接有提到只有保證 99% 的時間可以達到宣稱的效能:

AWS designs gp2 volumes to deliver their provisioned performance 99% of the time.

而 gp3 則是只用行銷宣稱「consistent baseline rate」,連 99% 都不保證:

These volumes deliver a consistent baseline rate of 3,000 IOPS and 125 MiB/s, included with the price of storage.

io* 的部份則是保證 99.9%:

Provisioned IOPS SSD volumes use a consistent IOPS rate, which you specify when you create the volume, and Amazon EBS delivers the provisioned performance 99.9 percent of the time.

另外在測試中 gp2gp3 的 throughput 看起來也沒調整成一樣的數字。在 1TB 的 gp2 中會給 250MB/sec 的速度,1TB 的 gp3 則是給 125MB/sec,除非你有加買 throughput。

另外從這句也可以看出來他對 AWS 不熟:

The tests were only run in a single availability zone (eu-west-1a).

在「AZ IDs for your AWS resources」這邊有提過不同帳號之間,同樣代碼的 AZ 不一定是一樣的區域,需要看 AZ ID:

For example, the Availability Zone us-east-1a for your AWS account might not have the same location as us-east-1a for another AWS account.

To identify the location of your resources relative to your accounts, you must use the AZ ID, which is a unique and consistent identifier for an Availability Zone. For example, use1-az1 is an AZ ID for the us-east-1 Region and it is the same location in every AWS account.

在考慮到只有設定大小與 IOPS 的情況下,剩下的測試結果其實跟預期的差不多:io2 貴但是可以得到最好的效能,io1 的品質會差一些,gp3 在大多數的情況下其實很夠用,但要注意預設的 throughput 沒有 gp2 高。

MIT 終止與 Elsevier 的合約

美國在今年有不少學校開始跟進,終止與 Elsevier 的合約了。

首先是去年 (2019) 三月加州大學系統宣佈不跟 Elsevier 續約 (參考當時寫的「加州大學宣佈不與 Elsevier 續約」這篇),今年四月則是北卡大學系統宣佈不續約:「Upcoming Elsevier Cancellations」,以及紐約大學系統也宣佈不續約:「State University of New York Steps Away From the “Big Deal” with Elsevier」。

到這邊看到的消息主要都是公立學校系統在開槍,直到前幾天 MIT 也放新聞稿開槍宣佈不續約了,這應該是第一個頂級的私校開槍的消息:「MIT, guided by open access principles, ends Elsevier negotiations」。

維基機百科上查資料的時候,發現台灣在 2016 年底 CONCERT 就宣佈放掉 Elsevier 了,當時有發稿出來:「關於 Elsevier 資料庫合約談判 CONCERT 聲明」。

In Taiwan more than 75% of universities, including the region's top 11 institutions, have joined a collective boycott against Elsevier. On 7 December 2016, the Taiwanese consortium, CONCERT, which represents more than 140 institutions, announced it would not renew its contract with Elsevier.

CloudFront 的 access log 多了一些欄位

CloudFront 的 access log 多了一些欄位可以抓:「Amazon CloudFront now provides seven new data fields in access logs」。

官方這次加了七個欄位,看起來後面六個都還蠻有用的... (第一個 c-port 是 client 的 port,目前只想的到 debug 時可以拿出來看...)

而第二個的 time-to-first-byte 可以拿來分析效能,這是從 CloudFront 的角度來看的。

第三個的 x-edge-detailed-result-type 是錯誤時的處理,讓管理者可以從 access log 直接粗略分析。

剩下的四個都是跟 content type 與 length/range 有關,之前居然沒有嗎...