Category: Computer

Cisco 併購 Splunk

Hacker News 上看到的消息，Cisco 買 Splunk：「Cisco Acquires Splunk (splunk.com)」，對應的新聞稿：「Splunk and Cisco Unite To Accelerate Digital Resilience as One of the Leading Global Software Companies」。

看不太出來為什麼 Cisco 要買 Splunk 這家公司，不知道戰略是什麼...

另外在 Hacker News 上的討論整片都有提到 Splunk 貴到哭爸的事情... 剛好前公司也有用，那個價錢的確是很哭爸，也因此有了後續 migrate 到 Prometheus 上的計畫，不過這也是過去式了...

That's staff, the building, equipment, power, water, everything...the estimated Splunk cost was more than that.

The joke used to be 'splunk is amazing until the first invoice comes in', it's funny because it's true. Note Datadog is very similar in that regard.

現在已經比起 Splunk 出來的年代，多了很多 open source 的方案可以選擇，Splunk 的吸引力低很多了。

Ruby 3.3 的速度再次提升

在「Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster」這篇提到了 Ruby 3.3 的速度再次提升的消息。

在 Shopify 上面的測試，3.3.0-preview2 的速度已經比 3.2.2 (兩者都有開啟 YJIT) 快了 13%，而且 p50/p90/p99 都有對應的改善：

不過有提到一些要注意的點，像是記憶體的用量又會再更高 (本來開 YJIT 的時候就已經有增加了)，如果是對記憶體比較敏感的環境，會需要注意這點：

Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT. We’re looking into skipping compilation of paths that are less frequently executed.

但 server 端應該是還好 (記憶體給多一點)，整體是個可以期待的方向...

Google 翻譯的中文詞彙

先前在網路上看到「Google 翻譯修好了沒？ Has Google Fixed Translate Yet?」這個網站，看起來是 2021 年的時候建立的，整理出來希望可以改善 Google 翻譯在台灣所使用的中文 (zh-tw) 的翻譯品質，上面列了五十幾個詞彙，記得當時只有一個有修正，其他都還是中國或是香港的用語。

(話說 Google 翻譯的介面好像沒有分台灣跟香港...)

因為看到有英文的說明，就順手丟上 Hacker News：「Has Google Translate been fixed yet? (isgooglefixed.tw)」，還蠻意外的有些關注與討論... 大概是因為這樣，可能讓 Google 內有個整理過資料可以開 issue，過了一個月，上個禮拜陸陸續續被修正了不少詞彙，目前剩下的那幾個比較接近詞彙準確性的問題。

下一個可能是 Google Maps 上面的翻譯問題？就算切到 zh-tw 下還是會出現港式翻譯：

而把 Google Maps 英文版上看到的「Chophouse restaurant」丟進 Google Translate 翻譯是：

Linux Kernel 後續的 LTS 版本將縮短成兩年

在「Long-term support for Linux kernel to be cut as maintainence remains under strain」這邊看到 Linux Kernel 後續的 LTS 版本將縮短成兩年的消息：

Here's one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.

主要的原因是舊版用的人並不多：

Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.

而目前的 LTS kernel 還是會走完本來計畫的時間，4.14、4.19、5.4 以及 5.10 從表上看都是六年，5.15 是五年，最新的 LTS 6.1 則是四年。

降到兩年的話，代表各家 Linux distribution 在 LTS kernel 跑完生命週期後就得自己維護安全性更新了，或是直接升級到另外一個 kernel 版本 (後者的方法風險高一點，不確定系統的相容性)。

看起來 5.10 與 6.1 會跑很久了，都到 2026 年十二月...

OpenTF (Terraform 的 fork) 改名為 OpenTofu

在「OpenTF 開張」這邊提到 Terraform 的 fork 叫做 OpenTF，現在改名為 OpenTofu：「New name for the OpenTF project #296」，同時也可以從官網看到正式加入 The Linux Foundation Projects。

有幾個報導都有提到了：「Terraform fork gets renamed OpenTofu, and joins Linux Foundation」、「Terraform fork OpenTF renamed and relocated as OpenTofu」。

看了 Hacker News 上的討論，據說 cli 也會從 tf 換成 tofu...

Cavium (被 Marvell 併購) 在 Snowden leak 中被列為 SIGINT "enabled" vendor

標題可能會有點難懂，比較簡單的意思就是在 Snowden 當年 (2013) 洩漏的資料裡面發現了不太妙的東西，發現 Cavium (現在的 Marvell) 的 CPU 有可能被埋入後門，而他們家的產品被一堆廠商提供的「資安產品」使用。

出自 X (Twitter) 上面提到的：

這段出可以從 2022 年的「Communication in a world of pervasive surveillance」這份文件裡面找到，就在他寫的 page 71 (PDF 的 page 90) 的 note 21：

While working on documents in the Snowden archive the thesis author learned that an American fabless semiconductor CPU vendor named Cavium is listed as a successful SIGINT "enabled" CPU vendor. By chance this was the same CPU present in the thesis author’s Internet router (UniFi USG3). The entire Snowden archive should be open for academic researchers to better understand more of the history of such behavior.

Ubiquiti 直接中槍...

而另一方面，在 Hacker News 上的討論「Snowden leak: Cavium networking hardware may contain NSA backdoor (twitter.com/matthew_d_green)」就讓人頭更痛了，像是當初 Cavium 就有發過新聞稿提到他們是 AWS CloudHSM 的供應商：「Cavium's LiquidSecurity® HSM Enables Hybrid Cloud Users to Synchronize Keys Between AWS CloudHSM and Private Clouds」。

而使用者也確認有從 log 裡面看到看到 Cavium 的記錄：

Ayup. We use AWS CloudHSM to hold our private signing keys for deploying field upgrades to our hardware. And when we break the CI scripts I see Cavium in the AWS logs.

Now I gotta take this to our security team and figure out what to do.

居然是 CloudHSM 這種在架構上幾乎是放在 root of trust 上的東西...

Java 21 (LTS) 推出

Hacker News 上注意到 Java 21 的消息：「JDK 21 Release Notes」、「Java 21 / JDK 21: General Availability」、「OpenJDK JDK 21 General-Availability Release」。

對於沒什麼在寫 Java 的人來說 (也是等於比較沒有在接觸 Java 圈子消息的人)，比較意外的是這是推出的是 LTS 版本，距離上次的 LTS (Java 17) 才兩年前 (2021/09/14)：

JDK 21 will be a long-term-support (LTS) release from most vendors, including Oracle. If you’re upgrading from the previous LTS release, JDK 17, then you have many more JEPs to look forward to, summarized here:

翻了一下 Java version history，可以知道同時支援的 LTS 版本變成四個了，而最近一次會終止的會是 Java 11，Red Hat 會在 2024/10 終止，而 Oracle 會在 2026/09 終止，這中間還會不會再增加 LTS...？

雖然沒什麼在寫，但還是常常會看到有人提到這次引入了 Virtual Threads 與 Generational ZGC，這應該是討論度最高的。

看了 Virtual Threads 的說明，有種「反璞歸真」的感覺...

在二十年前的時候，就已經有很多 userland threading library，讓應用程式可以用 threading design pattern 開發程式，而當時 x86 下的作業系統開始要遇到多 CPU 的環境，才開始在 kernel 裡支援 threading，讓應用程式裡面的 threading 可以打散到多個不同的 CPU 上面。

記得當年 FreeBSD 4 之後對 SMP 與 threading 的爭論導致分家出 DragonflyBSD，而 FreeBSD 的多 CPU 效能與穩定性要一直到 FreeBSD 7 才穩了下來。

現在 Java 反過來為了降低 OS thread 造成的 overhead，讓 java.lang.Thread 可以跑在 userland 裡面，不要用 kernel 提供的 OS thread...

另外又讓我想到 kqueue、epoll 以及 libevent 的事情了，不過這扯遠了...

X/Twitter 又繼續在搞競爭對手的外部連結了...

八月的時候提過「X/Twitter 在惡搞外部連結結果被抓包玩陰的」這個，X (Twitter) 故意對某些網站 delay 個幾秒鐘再重導，當時爆料出來後就馬上拿掉了，結果這幾天又被抓到故技重施：「Twitter is Still Throttling Competitors’ Links—Check for Yourself」。

依照測試，Meta 家的 Facebook、Instagram 以及 Threads 都中獎，另外沒什麼意外的，Twitter 前頭頭跳出來開的 Bluesky 也都有被搞...

而且這次爆料出來後也沒有「迅速修正」了，到目前也都還是如此... 來看看後續？

IPv6 Excuse Bingo (IPv6 理由伯賓果？)

在「AWS IPv4 Estate Now Worth $4.5B (toonk.io)」這邊的討論意外的看到「IPv6 Excuse Bingo」這個網站...

這個 bingo 是動態的，每次 reload 都會有不同的版本出來，理由超多...

不過實際用 IPv6 network 後會發現各種鳥問題真的多，之前 (到現在) 最經典的就是 HE 跟 Cogent 的 IPv6 network 因為錢的問題談不攏而不通的問題，在維基百科上面就有提到從 2009 年開始就不通了：

There is a long-running dispute between the provider Cogent Communications and Hurricane Electric. Cogent has been refusing to peer settlement-free with Hurricane Electric since 2009.

所以夠大的服務如果要弄 IPv6 都得注意到這點，像是 CDN 或是 GeoIP-based load balancer 就不能把 Cogent 的用戶導到 HE 的位置上面，反之亦然。

不過話說 AWS 手上有 128M 個 IPv4 address，整個 IPv4 address 的空間也才 4.29B，也就是說光 AWS 手上就有大約 3% 的 IPv4 address 空間，如果扣掉不可用的區段的話就更高了...

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) 期間都得自己維護了？其他作業系統應該也會有類似的問題...