KeePassX 宣佈不再維護了

Daily Lobsters 上看到 KeePassX 宣佈不再繼續維護了:「Development stopped」,在 Lobsters 上的討論也可以翻翻:「KeePassX development stopped」。

KeePassX 與 KeePassXC 都是 open source 版本的 password manager,單檔的設計可以配合很多不同的服務同步,自己架 Syncthing 或是用 Dropbox 之類的同步都是可行的,看對安全性的要求如何。

KeePassX 上次的更新是 2016 年推出的 2.0.3,已經超過五年沒有更新了。官方建議的替代方案是 KeePassXC

KeePassX is no longer actively maintained.

You might want to switch to KeePassXC which is based on KeePassX.

算是接棒交接出去...

受到 Log4j2 影響的清單

最近大家都在忙著補 Log4j2 的安全漏洞 (先前在「Log4j2 的 RCE」這邊有提到),有人整理了目前受到影響的軟體的清單以及對應的討論連結:「Log4Shell log4j vulnerability (CVE-2021-44228) - cheat-sheet reference guide」。

用這包來翻起來會方便一些,另外也可以順便翻一下有什麼其他軟體中獎...

然後 Cloudflare 的 CEO Matthew Prince 在 Twitter 上有提到從他們家的資料看起來,2021/12/01 就已經有攻擊在外面跑了,這也是之前會說這是 0-day 的原因:

來看 Intel + Varnish 的單機 500Gbps 的 PR 新聞稿

在「Varnish Software Achieves 500Gbps Throughput Per Server for UHD Video Content」這邊看到 PR 稿,由 IntelVarnish 合作,宣稱達到單機 500Gbps 的 throughput 了:

According to Varnish Software, the following were the outcomes of the test:

  • 509.7 Gbps live-linear throughput, using a dual-processor configuration
  • 487.2 Gbps video-on-demand throughput, using a dual-processor configuration

白皮書在「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」這頁可以用個資交換下載,不過用搜尋引擎找一下可以發現 Intel 那邊有放出 PDF (但不確定兩邊給的是不是同一份):「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」。

單 CPU 的伺服器是四個 100Gbps 界面接出來,雙 CPU 的伺服器是八個 (這邊 SUT 是 system under test 的縮寫):

These client systems were connected to the CDN servers using 100 GbE links through a switch; 4x100 GbE connections for the single-processor SUT, and 8x100 GbE for the dualprocessor SUT. Testing was done using Wrk, a widely recognized open-source HTTP(S) benchmarking tool.

不過如果實際看圖會發現伺服器是兩個 100Gbps (單 CPU) 與四個 100Gbps (雙 CPU),然後 wrk 也吃了兩個或是四個 100Gbps:

在白皮書最後面也有提到測試的配置,都是在 Ubuntu 20.04 上面跑,單 CPU 用的是兩張 Intel 的 100Gbps 網卡,雙 CPU 的用的是四張 Mellanox 的 100Gbps 網卡:

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Single processor SUT configuration was based on the Supermicro SMC 110P-WTR-TNR single socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by two 100 GbE Intel® Ethernet Network Adapters E810. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 8 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80 generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnishplus-6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Dual processor SUT configuration was based on the Supermicro SMC 22OU-TNR dual socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by four 100 GbE Mellanox MCX516A-CDAT adapters. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 12 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80- generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnish-plus6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

不過馬上就會滿頭問號,四張 100Gbps 是怎麼跑到 500Gbps 的頻寬...

這份 PR 馬上就讓人想到 Netflix 先前放出來的投影片 (先前有在「Netflix 在單機服務 400Gbps 的影音流量」這篇提到),在 Netflix 的投影片裡面有提到他們在 Intel 平台上面受限於記憶體的頻寬,整台機器只能跑到 230Gbps。

另外一種猜測是,如果 Intel 與 Varnish 宣稱的 500Gbps 是算 switch 上的總流量 (有這樣算的嗎,你是 Juniper 嗎...),那這邊的 500Gbps 換算回去差不多就是減半 (還很客氣的沒把 cache 沒中需要去 origin server 拉資料的流量扣掉),跟 Netflix 在 FreeBSD 上跑出來的結果差不多啊...

坐等反駁 XDDD

獨立遊戲創作者推出 Linux 版的好處

標題不知道怎麼下,大概就是這樣...

Hacker News 首頁上翻到的,以這個 upvote 數量來看,應該會收到今天的 Hacker News Daily 上:「Despite having just 5.8% sales, over 38% of bug reports come from Linux (reddit.com)」。

作者是一位獨立遊戲開發者,在兩年前推出了「ΔV: Rings of Saturn」這款遊戲,並且也發佈了 Linux 版。

作者先就數字來比較,他賣出了 12000 套,其中 700 套是 Linux 玩家;另外他收到了 1040 個 bug report,其中大約 400 個是從 Linux 玩家回報的:

As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.

That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.

看文章時可能會覺得「Linux 玩家真難伺候」,但實際上作者講到,這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上),其他的 bug 其實是所有平台都會發生:

A lot of extra work for just 5.8% of extra units, right?

Wrong. Bugs exist whenever you know about them, or not.

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]

原因是 Linux 社群在參與各種 open source project 養成的習慣,會盡可能把各種資訊講清楚,並且找出可以重製問題的方式:

The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

But that’s not all. The report quality is stellar.

與一般玩家的回報方式完全不同,Linux 玩家很習慣就會附上基本的環境資訊,系統紀錄,甚至有時候還會包括 core dump 與 reproducible steps:

I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.

And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

不知道有沒有遇到回報 GDB 資訊的...

很特別的分享 XDDD

Memcached 與 Redis 的比較

在「Memcached vs Redis - More Different Than You Would Expect」這邊看到對 MemcachedRedis 的分析。

這兩套軟體都很常被拿來用作 cache 機制,所以一般來說比較時就是比兩邊都有的東西 (如果你要 pub-sub 之類的東西,在這兩套裡面只有 Redis 有)。

最前面還是先講了對使用者 (開發者) 的差異,很明顯的是 Redis 對各種不同的資聊結構都有支援,這點可以從 Redis 被官方被稱作 Data Structures Server 就可以知道 (在「An introduction to Redis data types and abstractions」這篇可以看到),而 Memcached 只支援了 key-value 架構。

不過如果是以 cache 來說,的確 key-value 架構就還蠻好用的。

後面就開始比較硬的主題了,提到了 Memcached 與 Redis 內部是怎麼使用記憶體的。

Memcached 的部份先提了 page/slab/chunk 的架構以及產生的效能限制與浪費,接著有提到 2020 年 refactor 的部份 (太久沒有看 Memcached 的消息,去年沒跟到這個部份),讓多 CPU 的支援度更好。

Redis 則是靠 jemalloc 來處理這個部份,另外加上 background thread 的機制降低 fragment。

然後是比較 cache expiration 的部份,可以看到兩者用的演算法在現實世界中都夠用 (尤其是當作 cache 來用),這部份跟印象中的架構差不多,應該是沒有太大變化。

最後是比較 cluster 的部份,Memcached 是 share nothing,所以沒什麼好說的,主要是靠 client library 實做 consistent hash 之類的架構打散;而 Redis 的話看起來有實做新的機制出來 (也沒跟到),之後有機會再看看可以做到什麼程度。

不過好像沒提到 proxy 之類的架構,基本上各大公司都有自己幹:

少了這塊對於 cluster 架構的完整性差蠻多的。

文章最後沒有下定論一定要用哪個比較好,兩者都有強項與弱項,還是得看情況來處理。不過我自己還是很喜歡用 Memcached 就是了...

EULA 不能禁止使用者 decompile 修 bug

Hacker News Daily 上翻到的,歐洲法院認為 EULA 不能禁止使用者 decompile 修 bug:「EU court rules no EULA can forbid decompilation, if you want to fix a bug (europa.eu)」,官方的英文版文件在這邊可以翻到,不過原始判決是法文:

* Language of the case: French.

這是 Top System SA 與比利時政府打的訴訟,法院認為修 bug 而需要 decompile 這件事情是合法的,即使考慮到 Article 6 的規範:

In the light of the foregoing considerations, the answer to the first question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program is entitled to decompile all or part of that program in order to correct errors affecting its operation, including where the correction consists in disabling a function that is affecting the proper operation of the application of which that program forms a part.

In the light of the foregoing considerations, the answer to the second question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program who wishes to decompile that program in order to correct errors affecting the operation thereof is not required to satisfy the requirements laid down in Article 6 of that directive. However, that purchaser is entitled to carry out such a decompilation only to the extent necessary to effect that correction and in compliance, where appropriate, with the conditions laid down in the contract with the holder of the copyright in that program.

案子看起來應該還有得打?看起來好像不是最終判決...

REQUEST for a preliminary ruling under Article 267 TFEU from the Cour d’appel de Bruxelles (Court of Appeal, Brussels, Belgium), made by decision of 20 December 2019, received at the Court on 14 January 2020[.]

但不管怎樣,算是有些東西出來了... 然後 Hacker News 上面的討論就看到一些很歡樂的例子:

This becomes incredibly interesting in terms of e.g. Denuvo. This anti-piracy middleware has been shown to make games unplayable, and this EU law seems to support removing it.

哭啊怎麼提到該死的 Denuvo XDDD

用 Gecko Engine 寫的另外一個瀏覽器 Dot

Hacker News 首頁上看到 Dot 這個瀏覽器,平常看各種標語已經麻木了 (什麼 privacy enhanced 之類的),讓鄉民看上眼的是,這是一個 Gecko 寫的瀏覽器,也就是 Firefox 的底層,而不是 Blink (就 Google Chrome 那個系列):「Dot Browser – privacy-conscious web browser (github.com/dothq)」。

抓下來跑了一下,看起來就如同 GitHub 頁面上的警告:

Dot Browser is alpha software, and you will most likely experience bugs and issues!

目前功能也超陽春,還沒支援 extension 之類的東西... 不過是有內建 ad blocking 與 usercss 的能力,算是基本盤吧。

可以放著看看發展的如何...

用 Flatpak 跑 Zoom,限制 Zoom 的存取

昨天在 Hacker News Daily 上看到的討論,有人發現 ZoomLinux 版掃了所有 process 的資訊:「Ask HN: Why does Zoom Desktop examine all processes and arguments?」。

twic 給了個建議,用 Flatpak 在 sandbox 裡面跑 Zoom:

I run Zoom from flatpak, which runs it in a container, and sandboxes it to some extent [1]

This probably explains why, when i try to screenshare a single application window, not every application shows up! I can share my browser, file manager, and various other things, but not windows for games started by Steam.

[1] I followed these instructions https://www.mayrhofer.eu.org/post/zoom-flatpak-sandboxing/

測了一下沒什麼問題,應用程式安裝完後可以直接用 flatpak run us.zoom.Zoom 跑,但如果想要直接在 launch menu 叫出來的話 (在 Xfce 叫 whiskermenu),需要重開機 (看起來至少要 relogin)。

應該就會先暫時這樣,稍微擋一些 Zoom 可以看到的資訊。而且 Zoom 本身的安裝一直都沒有更新機制,透過 flatpak 包起來反而可以跑 flatpak update 更新,目前感覺應該是 Z >> B...

0.x 版的 ZeroVer

Hacker News Daily 上看到「ZeroVer: 0-Based Versioning (0ver.org)」這個討論,原網站在「ZeroVer: 0-based Versioning」這邊。

這應該是從 Semantic Versioning 出現 (看起來是 2009 年?) 而且被廣泛應用後的現象,就是大家都不想負責 XDDD

在 Semantic Versioning 裡面有提到 0.x 版的特殊性,也就是什麼都不保證:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

因為 Semantic Versioning 被廣泛應用後,這個特性也深受開發者喜愛 (即使軟體變得很成熟),於是 ZeroVer 這個站台就整理了一堆仍在使用 0.x 的軟體...

其實我覺得這樣很好,像是 HashiCorp 如果決定把軟體推出 1.0 版 (最近應該是 Terraform 的 1.0),表示他們對這個產品有一定的信心了,不然都還在摸索開發階段...

0.x 算是讓開發者可以很有信心的跟大家講「我沒信心」的方式 XD

GTA Online 釋出官方修正,大幅改善啟動效能

看到「GTA Online load time fix released, shaves off actual minutes of waiting for some」這邊的消息,先前在「GTA 的啟動讀取效能問題」這邊提到 GTA Online 啟動速度很慢的問題,官方正式推出修正版本了:「GTAV Title Update 1.53 Notes (PS4 / Xbox One / PC)」。

抓了一些在 Reddit 的討論「Loading Times Have FINALLY been patched - Discussion Thread」。

這則降的比率與當時 workaround 的修正差不多:

Insane. GTA menu -> GTA: Online.

Dropped from 7 minutes to 1:57

i7-2600k,GTX1070,16GB RAM and the game is on HDD.

這個就有點誇張了,這是 90% 吧?

Dropped from 5-8 minutes to 35 seconds

這個差不多 70%~80%:

Loading time 2m 20s for online directly from steam. Before it was like 8-10 minutes for me. Damn

Edit: 50s for story mode. 35s from story mode to online. So it seems it's still faster to load into online from story mode.

這個也差不多 70%:

From 4-5 minutes to 1 a minute and 22 seconds. Y e s p l e a s e

然後 PS4 的版本原來也受到一樣的影響?

Currently tested on PS4 , from main menu to online : 3min 45 sec From story mode to online: 1min 20sec (😩 i can't tell for sure )

整體看起來是正面的,畢竟大家等這個問題等超久了... 另外也可以看出來當初的 workaround patch 其實相當精準的把問題都解掉了,官方的修正並沒有快更多。

來繼續關注 libc 那邊的問題...