Google Play 將終止對 Android 4.4 的更新

Google 宣佈從八月開始將不再更新 Android 4.4 (KitKat,KK) 的 Google Play 服務:「Google Play services discontinuing updates for KitKat (API levels 19 & 20) starting August 2023」。

Therefore, we are no longer supporting KK in future releases of Google Play services. KK devices will not receive versions of the Play Services APK beyond 23.30.99.

可以看到講的是 client 端的 apk 停止更新,服務應該還是可以用一陣子,直到 Google Play 有改動,讓舊版的 client 無法用。

Android 4.4 也是個經典的版本,當初在用 LG G2 的時候是 4.2,用了一陣子有 4.4,最後一版是 5.0,再新的版本就得刷機用第三方了。

AWS 將開始收取 IPv4 的 Public IP 費用

一個蠻大的改變,AWS 宣布所有的 IPv4 address 將在明年二月開始收費:「New – AWS Public IPv4 Address Charge + Public IP Insights」。

這包括了有掛在 EC2 上面的 IPv4 address:

We are introducing a new charge for public IPv4 addresses. Effective February 1, 2024 there will be a charge of $0.005 per IP per hour for all public IPv4 addresses, whether attached to a service or not (there is already a charge for public IPv4 addresses you allocate in your account but don’t attach to an EC2 instance).

費用算是相當貴,$0.005/hr 已經比 t4g.nanous-east-1 的 $0.0042/hr 還貴了。

另外一個有趣的點是 Jeff Barr 會自己貼到 Hacker News 上?在「AWS Public IPv4 Address Charge and Public IP Insights (amazon.com)」這邊可以看到。

回到原來的主題,改跑 IPv6 only 會有兩個方向的流量要解決,一個是從機器連出來的部分,另外一個是從外面連到機器的部分。

對於比較大的服務,連出來的部分是可以靠 NAT64 類的方式處理掉 (但如果用 AWS 服務的話也很貴,參考 AWS 的 DNS64 and NAT64),或是透過 socks5 proxy 與 http proxy 解決。

而比較小的單機 (像是當 VPS 用的 EC2 instance) 似乎就沒有太好的解法了。

另外從外面連到機器的部分,如果只有 HTTP(S) protocol 還可以加減透過 CDN 解 (像是 Cloudflare 或是 AWS 本家的 CloudFront),但 SSH 類的服務就稍微麻煩了,台灣要弄到便宜的固定 IPv6 address 有點麻煩,HiNet 的企業固定制是有對應的方案:「HiNet固定制IPv6服務說明」,但最低的 16M/3M 也要 $1292/mo (大約是 US$41/mo),可能要找有提供固定 IPv6 的 VPS?

雖然是個很靠悲的事情,但這也讓雲端架構裡面朝 IPv6 的動力多了點...

Tails 換網域名稱,從 tails.boum.org 換到 tails.net

看到 Tails 換了一個新的網域名稱,從本來的 tails.boum.org 換到了 tails.net 上:「Welcome to tails.net!」。

看了 tails.netWHOIS 可以發現這也是個老域名了,甚至比 Tails 軟體出現的 2009 年還早:

Updated Date: 2022-08-09T10:30:42
Creation Date: 2002-12-18T11:36:37
Registrar Registration Expiration Date: 2024-12-18T11:36:37

理所當然的,本來的 tails.boum.org 也還會動,目前是重導到 tails.net 上面。

然後研究了一下 boum.org 是什麼,用「site:boum.org -site:tails.boum.org」翻了一下各家搜尋引擎:「Kagi 的」、「DuckDuckGo 的」、「Google 的」。

其實還不少東西?看起來像是某個業餘團體或是組織...

另外如果是用 site:tails.boum.org 找,可以發現除了主站以外,下面其實還不少 subdomain,像是 gitlab.tails.boum.org 這樣的網域,所以應該是還有不少東西要改...

今年的 EFF Awards 頒給了 Sci-Hub 的創辦人 Alexandra Elbakyan

在「Sci-Hub’s Alexandra Elbakyan Receives EFF Award for Providing Access to Scientific Knowledge」這邊看到 EFF 把今年的 EFF Awards 頒給了 Sci-Hub 的創辦人 Alexandra Elbakyan。而 EFF 原始的公告在「Electronic Frontier Foundation to Present Annual EFF Awards to Alexandra Asanovna Elbakyan, Library Freedom Project, and Signal Foundation」這邊。

維基百科對 Sci-Hub 的介紹在開頭說的頗清楚,Alexandra Elbakyan 選擇無視 copyright,提供論文免費下載:

Sci-Hub is a shadow library website that provides free access to millions of research papers, without regard to copyright, by bypassing publishers' paywalls in various ways.

而 EFF 肯定這樣的行為促進了科學知識的傳遞:

Kazakhstani computer programmer Alexandra Asanovna Elbakyan founded Sci-Hub in 2011 to provide free and unrestricted access to all scientific knowledge.

很像是 EFF 會幹的事情沒錯 XDDD

Amazon S3 的新數字

Werner Vogels 寫了一篇在回憶 Amazon S3 的文章:「Building and operating a pretty big storage system called S3」,裡面有個是他這個層級比較容易取得公開權限的資料:

有標注「S3 by the numbers (as of publishing this post).」,所以是 2023 年七月現在的數字。

雖然很明顯的還是避開談總大小,但有提供目前的 S3 object 數量是 280 兆,以及 request 量是每秒 1 億次。

搭配之前公開過的數字 (出自維基百科上的「Amazon S3」條目),上次公佈是在 2021 年三月的時候宣布超過 100 兆,所以過了兩年的時間已經到 280 兆了:

Amazon Web Services introduced Amazon S3 in 2006. Amazon reported it stored more than 100 trillion objects as of March 2021, up from 10 billion objects in October 2007, 14 billion objects in January 2008, 29 billion objects in October 2008, 52 billion objects in March 2009, 64 billion objects in August 2009, 102 billion objects in March 2010, and 2 trillion objects in April 2013.

MySQL 改變發佈的方式,推出 LTS 版本

看到 Percona 寫的「LTS and Innovation Releases for Percona Server for MySQL」這篇,才注意到 Oracle 宣佈了 MySQLLTS 版本:「Introducing MySQL Innovation and Long-Term Support (LTS) versions」。

這次的改變產生了 Innovation 版本與 LTS 版本:

We're transitioning to the new MySQL versioning model with our upcoming versions. MySQL database version 8.1.0 will be our first Innovation release, and 8.0.34+ will transition to only bug fixes until 8.0 End-Of-Life (EOL) scheduled for April-2026. Approximately one year from now, MySQL version 8.x will eventually become LTS which will provide ample time for users to migrate from 8.0.x to the 8.x LTS version.

從這段的解釋看起來是在講從舊的發佈模式到新的發佈模式的轉換期特例,MySQL 8.0.34+ (應該是指 8.0 的後續這條,從 8.0.34 開始) 會支援到 2026 年四月,大約是再兩年半多;而 8.x (應該是指 >8.0 的這條?) 會在距今一年後 (大約是 2024 年年中?) 成為 LTS 版本。

接著的段落拿了一些範例說明:

In practice, in this transition period, if you want the latest features, improvements, and all bug fixes for your MySQL databases, use the Innovation release track (eg., 8.1.x, 8.2.x, 8.3.x, etc.). If you need only bug fixes for your MySQL database, use 8.0.x releases (eg., 8.0.35, 8.0.36, 8.0.37, etc.). In both cases, you should plan to update your MySQL databases quarterly accordingly to Oracle Critical Patch Updates (CPU) calendar. When 8.x becomes LTS, you can plan, test, and migrate from the 8.0.x bug fix track to the LTS release track (ex., from 8.0.37 to 8.4.1).

看起來 8.0 是轉換期的特殊待遇,看起來有點像是 LTS 的 security update only?然後是官方給的這張圖,要注意這張圖下面有提到這張圖只是示意,實際發生的時間點可能會有改變,不過也可以看出來在 8.0 的地位比較特別:

Note that this is an example, there is no commitment that the version numbering will be exactly as presented.

而 LTS 的頻率會是兩年一版,支援 5+3 年,而 8.0 會走四年半:

About every 2 years, a minor version will be designated as Long Term Supported release. This version will have a 5 year premier and 3 year extended support, the same as the previously supported releases. This is similar to MySQL 5.7 and previous releases.

The LTS will also be the last version of the major release. The next (Innovation) release will increase it's major version. For example if MySQL 8.4.0 is the 8.x LTS release, then MySQL 9.0 will be the next Innovation release.

另外後面有提到他們會確保 LTS 在升級時會用到的方式,看了一下沒有太多意外,跟之前在 5.x 年代的感覺差不多。

倒是降級這件事情他們也提出方案,這點就蠻值得看一下了... 然後這邊可以看到 async replication 果然超萬用的。

基本上就是 release cycle 改變的公告,現在這個階段繼續黏在 8.0 上面應該就可以了,後續等第一個 LTS 的消息。

CloudFront 支援 3072 bit RSA 憑證

看到 CloudFront 支援 3072 bit RSA certificate 的消息:「Amazon CloudFront announces support for 3072-bit RSA certificates」。

2048 bit 在一般情況算是夠用,畢竟現在的紀錄也才到 829 bit (參考「RSA Factoring Challenge」):

1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys, 3072-bit RSA keys to 128-bit symmetric keys, and 15360-bit RSA keys to 256-bit symmetric keys. In 2003, RSA Security claimed that 1024-bit keys were likely to become crackable some time between 2006 and 2010, while 2048-bit keys are sufficient until 2030. As of 2020 the largest RSA key publicly known to be cracked is RSA-250 with 829 bits.

但如果哪天突然又有新的演算法出來威脅到 2048 bit 的話,會多一點緩衝的空間?

AlmaLinux 放棄 1:1 clone RHEL

上個禮拜的資訊了 AlmaLinux 最後決定放棄 clone RHEL:「The Future of AlmaLinux is Bright」。

After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*.

這樣在市場上有 Rocky LinuxSUSE 也打算要搞自己的 RHEL clone 的前提下,沒有使用 AlmaLinux 的誘因,標題說的 bright 就是講講而已。

華碩接手 Intel NUC 的維護與後續研發

Intel 發新聞稿,說跟 ASUS 簽了約,讓 ASUS 接手 Intel NUC 的維護與產品研發了:「Intel and ASUS Agree to Term Sheet to Take Intel NUC Systems Product Line Forward」。

Today, Intel announced it has agreed to a term sheet with ASUS, a global technology solution provider, for an agreement to manufacture, sell and support the Next Unit of Compute (NUC) 10th to 13th generations systems product line, and to develop future NUC systems designs.

不過 ASUS 這邊網站上還沒看到新聞稿...

前幾天 Intel 宣佈要停止 Intel NUC 產品線,但當時沒看到接手的消息:「Intel Exiting the PC Business as it Stops Investment in the Intel NUC」。

有可能是消息出來後 ASUS 才去談的?或是一開始 Intel 就有找 partner 談,但談到一半消息先走漏了,但外面只聽到 Intel 不做?

Anyway,這樣 ASUS 算是官方指名的繼承人,讓後續要買的人可以過去看看;以 ASUS 本來就有自己的便當盒產品線 (像是 PChome 24h 上面的「ASUS-特規/改機專區 品牌館」),就是讓現有的團隊接手一個知名的產品線,不過本來跟精英 & 和碩的代工不知道會出現什麼變化...

strlcpy() 與 strlcat() 被加入 glibc

Hacker News 上看到「Strlcpy and strlcat added to glibc 2.38 (sourceware.org)」這個,印象中極度排斥 strlcpystrlcatglibc 要包進去了。

主要的原因在原始的 commit log 裡面有提到,是因為 POSIX 標準要放入這兩個 function 了:

These functions are about to be added to POSIX, under Austin Group issue 986.

找了一下提到的 Austin Group issue 986,最後更新是 2022 年,看起來進度不快,但是就是一直推進?

反過來看了一下 Hacker News 上的討論,果然有人把當年 Ulrich Drepper 臭 BSD 流派的信件翻出來:「Re: PATCH: safe string copy and concetation」。