MySQL 5.7 已經 EoL

查資料發現忘記這件事情了... 先前就有寫過 MySQL 5.7 到今年十月就 EoL 了:「MySQL 5.7 的支援只到今年十月 (Oct 2023)」。

最後一版是 2023/10/25 釋出的 5.7.44:「Changes in MySQL 5.7.44 (2023-10-25, General Availability)」。

MySQL 5.7.44 is the final release of the MySQL 5.7 series.

然後 MySQL 8.1 也是十月 EoL。

雖然目前已經有 MySQL 8.2 了,但 MySQL 8.0 是 LTS,目前預定支援到 2026 年四月 (大約還有兩年多),所以除非有需要用到 MySQL 8.2 的新功能或是特性,不然應該還是會先繼續用 MySQL 8.0...

然後翻了一下 Percona Server for MySQL,看起來還是沒有提供 ARM 的 binary 可以裝,所以在 ARM 上面的機器比較方便的還是裝 MariaDB 了...

OpenSSL 1.1.1 EoL

看到 OpenSSL 官方的公告,1.1.1 版 EoL:「OpenSSL 1.1.1 End of Life」(btw,我不知道他們為什麼網址上會放兩個 /blog/...)。

OpenSSL 1.x 與 3.x 最大的差異就是他的 license 了,1.x 版是 dual license,但這兩個 license 都與 GPL 不相容:

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used. The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License.

As the OpenSSL License was Apache License 1.0, but not Apache License 2.0, it requires the phrase "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising material and any redistributions (Sections 3 and 6 of the OpenSSL License). Due to this restriction, the OpenSSL License and the Apache License 1.0 are incompatible with the GNU GPL.

後續 3.x 的版本則改成 Apache License 2.0 了:

OpenSSL announced in August 2015 that it would require most contributors to sign a Contributor License Agreement (CLA), and that OpenSSL would eventually be relicensed under the terms of Apache License 2.0.

不過 Apache License 2.0 與 GPLv2 還是不相容 (但相容於 GPLv3),這個更換只是換成一個比較常見的 license:

The Free Software Foundation considers all versions of the Apache License to be incompatible with the previous GPL versions 1 and 2.

話說 Ubuntu 20.04 內的 OpenSSL 是 1.1.1f,看起來光是標準的 LTS (到 2025/04) 期間都得自己維護了?其他作業系統應該也會有類似的問題...

Backblaze 2023 Q1 的硬碟資料

Backblaze 放出 2023 Q1 的硬碟生存資料:「Backblaze Drive Stats for Q1 2023」。

這次意外看到 WDC 的表現超級好:

看了一下型號,WUH 開頭的,看起來是之前 HGST 的 model,而不是 WDC 自家的型號... (備註一下,WDC 在 2012 年就買下 HGST 了,但到了 2018 廢掉了 HGST 的 branding)

所以整體看起來 HGST 的硬碟還是首選...

ISC DHCPD 要 EoL

看到「ISC DHCP Server has reached EOL」這個,月初的時候 ISC 宣佈了 EoL,除非有嚴重的安全性問題冒出來,不然官方打算停止維護了:

The 4.4.3-P1 and 4.1-ESV-R16-P2 versions of ISC DHCP, released on October 5, 2022, are the last maintenance versions of this software that ISC plans to publish. If we become aware of a significant security vulnerability, we might make an exception to this, but it is our intention to cease actively maintaining this codebase.

ISC 則是在推 Kea

Network and system administrators deploying DHCP in new environments should look beyond ISC DHCP for a solution, as it would be irresponsible to invest in new deployments of this software which is now end-of-life. Naturally, ISC suggests new users consider our Kea DHCP server, but there are alternatives.

從維基百科上的「Comparison of DHCP server software」這頁可以看到目前 DHCP server 的選擇。最直接的差異是,其他非 ISC 的全部都是 GPL,只有 ISC 的是 non-GPL。

不過一般不太會自己架 DHCP server,大多是用設備內建裝的跑,以後如果有機會要裝的話,也許得去熟悉 Kea 了...

Cloudflare 的另外一個策略:不熱門的資料只放到記憶體內

前陣子的文章,Cloudflare 將不熱門的資料放到記憶體內,不寫到磁碟裡面:「Why We Started Putting Unpopular Assets in Memory」。

主要的原因是這些不熱門的資料常常是一次性的,寫到 SSD 裡面反而浪費 SSD 的生命。而且這樣做因為減少了寫入,反而可以讓 SSD 的讀取變快:

The result: disk writes per second were reduced by roughly half and corresponding disk hit tail latency was reduced by approximately five percent.

這個想法還蠻特別的,但好像印象中之前有人有提過類似的方法...

Anyway,這個想法不只在 CDN 這邊可以用到,對於有 memory + storage 架構的 cache system 也可以套用類似的道理,而要怎麼決定哪些 object 要寫到磁碟裡面的演算法就是重點了...

題外話,剛剛因為突然想到,瞄了一下 Squid,發現連 HTTPS 都還沒上...

SETI@home 計畫將在月底停止

看到「SETI@home Search for Alien Life Project Shuts Down After 21 Years」這個消息,SETI@home 計畫將在這個月月底停止:

SETI@home hibernation
On March 31, the volunteer computing part of SETI@home will stop distributing work and will go into hibernation.

大學的時候跑得很開心,後來就沒什麼在玩了... 看起來是有些成果,所以決定休息了。

Safari 將會禁止長效憑證 (超過 398 天,大約十三個月)

在「Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months」這邊看到的,這次是 Safari 直接發難要幹掉長效憑證。

今年九月前發的憑證是照既有的協議,最長長度是 825 天 (大約 27 個月),但九月開始發的憑證,如果有效長度超過 398 天就會直接被 Safari 視為無效,所以大約是砍半,其他家瀏覽器不知道會不會跟進...

最早的時候可以直接買五年 (有印像是因為當年的 group.nctu.edu.tw 是我自己買的),後來好像降到三年,最近是兩年,看起來要變成一年了...

LED 燈泡的壽命

在「What Happened to the 100,000-Hour LED Bulbs?」這邊看到在討論 LED 燈泡的壽命。比較感興趣的是到底業界怎麼計算 LED 燈泡的壽命。

前面提到很多因使用時間的增加而產生衰退與色偏,然後講到「壽命」的定義是,超過一半的燈泡低於 70% 的原始亮度所需要的時間:

Research says that most users won’t notice a gradual 30% drop in light levels; accordingly the industry has defined L70, the time at which the output has dropped to 70% of its initial level, as an endpoint for measuring LED bulb lifetime. Based on how it’s estimated, this measure is typically stated as B50-L70, the point at which 50% of an initial sample of bulbs will retain 70% of their rated output.

另外一個有趣的資料是,LED 燈泡故障的原因中,電源供應相關佔了最大的比率 (過半):

算是個有趣的知識...

在 2019 年出的 PHP 5.6.40...

剛剛才注意到 PHP 5.6 在 2019 年還有新的版本:「PHP 5.6.40 Released」。

在「Supported Versions」可以看到 PHP 5.6 應該是在 2018 年年底就終止更新,看起來是 5.6.39 在 2018/12/06 出之後,把剩下的一包都累積起來,「原則上」後面不會有更新:

Please note that according to the PHP version support timelines, PHP 5.6.40 is the last scheduled release of PHP 5.6 branch. There may be additional release if we discover important security issues that warrant it, otherwise this release will be the final one in the PHP 5.6 branch.

不過看起來官方的態度是「儘量幫」,如果有太嚴重的漏洞還是會補... :o

Python 2 的 EoL 日期將會是 2020 年年初

在「Python 2 EOL will be 2020-01-01」這邊看到的,文章標題的連結是 mailing list 上的內容:「[Python-Dev] Python 2.7 -- bugfix or security before EOL?」。

Guido van Rossum (Python 的發明人) 在回覆關於「Python Developer’s Guide — Python Developer's Guide」上面的資訊時的說明... 大約還有一年九個多月的時間。

然後發現原來 Python 在 release 時是會發佈 PEP 的,像是「PEP 373 -- Python 2.7 Release Schedule」這樣的資訊。其他版本可以在索引頁「PEP 0 -- Index of Python Enhancement Proposals (PEPs) | Python.org」翻到。