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 那邊的問題...

Airtable 的 Open Source 替代方案 Baserow

Hacker News Daily 上看到的產品 Baserow,另外在 Hacker News 的討論也有蠻多有趣的東西:「Baserow.io – Self-hosted Airtable alternative (baserow.io)」。

Baserow 的後端是用 Django 寫的,前端則主要是用 Vue.js

可以看到討論裡 Airtable 的問題,先不講定價問題,只講其他的部份... (因為就如同討論裡面有提到的,有可能是公司故意把定價策略訂成讓不願意花大錢的人使用)

首先是每個月都有「穩定的 downtime」,不過這邊的描述到的數字明顯有問題,一個月當了七個小時也有 99% uptime (兩個九)。

不過先撇開這點,付費服務一般都可以看到 99.9% 的 Monthly SLA (三個九,一個月只允許 43.2 分鐘),這個情況的確是不太符合業界的標準:

Reliable 1-5 hours a month of downtime. There are months where it's literally 1 nine of uptime. Their status page was actually down for a while (I think they forgot to renew it?)

另外一個有很趣的是很奇耙的設計:

Booleans in the API are `true` or `undefined`. Seriously.

看起來要有蠻多背景知識才有可能知道為什麼這樣搞 XDDD

先丟給 data team 看看,如果他們有興趣的話再找機會架起來...

Martin Fowler 在 2015 年寫的 MonolithFirst,以及 Microservice 的問題

Hacker News Daily 上看到「MonolithFirst」這篇,是 Martin Fowler 在 2015 年寫的文章,對應在 Hacker News 上的討論「Monolith First (2015) (martinfowler.com)」也頗有趣的,可以一起翻。

tl;dr:他的文章就是在講新專案用 monolith,不要去碰 microservice。

文章開頭提到了就他觀察到的情況:第一點是,幾乎所有成功的 microservice 案例都是從 monolith 起頭,再轉到 microservice 環境;第二點是,幾乎所有一開始用 microservice 的案例,在後來都遇到嚴重的問題:

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

  1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
  2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .

文章接著有兩個猜測,試著去解釋為什麼。

第一點可能的原因是 Yagni (You Aren't Gonna Need It),在試驗市場時 PoC 或是 MVP 的商業邏輯反而不會那麼複雜,快速用 monolith 開發驗證比起擁抱 microservice 來的重要太多,而且可以快速修改。

第二點分成兩個現象:第一個現象是,即使是對產品的商業領域很有經驗的資深架構師,也很難一開始就切出正確的 BoundedContext;第二個現象是,在 microservice 裡,改架構的難度比起 monolith 高非常多 (i.e. 跨 boundary 的 refactoring)。這兩個現象加在一起就會造成一開始導入 microservice 的專案失敗。

文章接著想要提出一些建議,在一開始使用 monolith 可以注意的方向,這些注意的事項可能可以讓之後轉成 microservice 變得比較輕鬆。

第一種方式是在 monolith 架構下注意 API boundary 與 data 的儲存方式,當想要切換到 microservice 的時候就有機會比較簡單。

第二種是更常見的方式,一開始先是 monolith 架構,然後把 boundary 好切割的拆成 microservice,所以在過度期會是一組不那麼大的 sub-monolith 架構,然後週邊圍繞著很多 microservice。這個做久了就有機會轉成全部都是 microservice。

第三種方式就是砍掉重練。

第四種方式是一開始的時候不用 monolith,而是幾個很大包的 service (所以一開始不太能叫 microservice),當商業模式成熟穩定後,切出更細緻的 boundary 的時候再拆成 microservice。

把這篇文章拿去搜尋 Hacker News 上的討論,可以看到除了 2021 年的這次討論外,在 2017 年的時候就有一批討論也蠻有趣的,可以看到有些不同的風向:「Monolith First (2015) (martinfowler.com)」。

當然也未必要信 Martin Fowler 的看法,軟體工程這塊還是有很多不同的流派...

Windows 上包裝 Syncthing 的 SyncTrayzor

在「SyncTrayzor is an open source Syncthing client for Windows」這邊看到有人將 Syncthing 包裝好,讓使用者在 Windows 上直接設定,而不需要另外開瀏覽器設定:

Syncthing is a popular peer-to-peer file sharing/synchronization software. It uses a web GUI which can be a little confusing for beginners. SyncTrayzor is an open source client that makes the P2P tool more user-friendly.

Syncthing 比較特別的觀念就是每一台都要設定允許其他台分享 (通常是這樣)。假設你有四台 Syncthing 要設定,每一台都要設定允許其他三台的分享。

不過也可以有其他的設計,像是你可以在 VPS hosting 上租一台空間很大的機器,然後其他機器都只對 VPS 這台機器同步,這樣就比較像有中央 server 的架構。

對於有多電腦的人還蠻好用的東西...

Nmap 變成非 Open Source Software

在 RSS reader 上看到「A license change for Nmap」這篇,雖然看不到內容,但標題已經先把重點講出來了 (雖然在 Hacker News 上找一下就有連結了),看起來 Nmap 的軟體授權有改過,查了一下是在去年十月出版的 7.90 發生的,不過最近突然被炒熱了起來:「Nmap 7.90 Released! First release since August 2019.」。

We also did some long-needed license cleanup and gave the license a name (Nmap Public Source License) to avoid the previous confusion of Nmap being under "GPLv2 with various clarifications and exceptions". The NPSL is still based on the GPLv2, but brings in terms from some other popular open source licenses. See https://nmap.org/npsl

看到這種自我宣稱的就超可疑,而翻了一下 NPSL 裡面的限制,看起來就不怎麼符合 open source license 的定義,在「Is nmap's custom NPSL license free?」這邊的說明算是很客氣了,都是掛上「probably」,不過大家自己讀過以後應該就會知道問題了...

目前開槍的應該就是 Fedora 了,Fedora 在 Nmap Public Source License (NPSL) Version 0.92 - devel-announce - Fedora Mailing-Lists 這邊決定把 NPSL 列為 bad license,並且在 Fedora 裡面禁用。

Debian 目前則是在「#972216 - nmap: New NPSL 0.92 license likely non-free - Debian Bug report logs」這邊也有類似的討論,不過目前看起來就還在討論,沒有動手。

Gentoo 跟情況跟 Debian 也類似,在「Add NPSL (nmap license) to MISC_FREE」這邊討論中。

看起來這幾天應該會有進展,沒意外的話應該是會被封殺,裡面的條款把 installer 之類的程式也都限制進去了,直接影響到 Linux 平台的各種工具 (像是 apt/dnf/yum)。

該拉個折凳,買個爆米花來等著看了...

Travis CI 停止提供服務給 Open Source 專案

Hacker News Daily 上看到這個,在講 Travis CI 終止對 open source 專案的服務:「Travis CI is no longer providing CI minutes for open source projects」。

有不少專案已經改用其他 CI 服務的 free tier 做,像是 GitHub ActionsCircleCI 都有提供。

看了一下 Hacker News 上的討論,不少人是可以理解不會有永遠免費的午餐,只是這次 Travis CI 的處理讓大家覺得比較討厭的是,一方面官方一直跟 open source community 說我們很願意支援 open source community (前幾個禮拜官方 blog 還有發文重申這件事情),另外一方面是一直在朝著關閉服務走:從限制 10K credits 開始,到現在不會再提供 credit 給 open source 專案。

有人整理了對應的時間軸:

? 2018: Travis CI announces they are starting the process of merging travis-ci.org, which provided free builds for OSS projects, into travis-ci.com, which until then was only for paying customers. They promise OSS builds will continue to be free.

? 2020: Travis CI announces they are shutting down travis-ci.org at the end of the year and all projects have to move to travis-ci.com. They promise OSS builds will continue to be free.

Early November 2020: travis-ci.com switches from providing unlimited builds for OSS to only providing 10k one-time credits by default. Projects that meet certain guidelines (e.g. no one paid to work on them) can apply for recurring credits.

Later in November 2020: CI for many OSS projects that had migrated to travis-ci.com starts to fail, as they've exhausted their 10K credits.

Dec 2020: If what is reported here is accurate, Travis CI stop providing any recurring OSS credits. CI breaks for the remaining OSS projects on travis-ci.com.

Jan 2021: travis-ci.org shuts down. CI will be broken for all projects using it. They'll have the option of migrating to travis-ci.com, but will soon break again as they exhaust their 10k credits.

這種服務非常吃 CPU resource,大型專案如果每個 push 或是每個 pull request 都跑一輪完整的測試,成本應該不低,大概可以理解為什麼 Travis CI 會這樣決定,不過態度就...

其他家有提供 free tier 的 CI 最近應該會湧入不少人,這幾個月可以看看其他家會不會也跟進,另外一方面應該也會有人開始自架?

Load Impact 的 k6 網站壓測軟體

這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式,結合了 Golang 的執行效率與 JavaScript 的操作語法,讓使用者可以很簡單的進行壓力測試,在 Hacker News 上也有蠻正向的反應:「K6: Like unit testing, for performance (github.com/loadimpact)」,我唯一會在意的應該是 AGPLv3 的部份...

先看了一下資訊,看起來「Load Impact」是公司名稱,「LoadImpact」則是產品名稱,然後現在要改名變成「k6」與「k6 Cloud」:

Load Impact is now k6

Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!

k6 裡面設計了 VU (Virtual User) 的概念,如同字面上的意義,VU 是虛擬的使用者,就技術上來說,每個 VU 都是在獨立的 JavaScript runtime 裡跑:

Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.

然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了,所以就不需要一堆 callback & promise 架構,用起來就爽很多:

For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.

翻了一下 Hacker News 上的討論與程式碼,看起來 JavaScript runtime 這部份是用 Golang 寫的 goja

文件裡面給了不少範例,像是在「Running k6」這邊有直接給出怎麼壓測,10 個 VU 跑 30 秒:

k6 run --vus 10 --duration 30s script.js

另外在 repository 裡面,「samples」這個目錄下有不少範例,可以直接先看過一次從裡面學到不少功能,之後再回去翻一次 manual,應該就會更熟悉...

隨便測了一下還蠻容易上手的,加上有 apt repository 可以直接納入系統管理,看起來應該會放著跑,之後找機會用看看,也許打 API 之類的...

lighttpd 居然出新版支援 HTTP/2 與 Brotli 了...

從 mailing list 收到 lighttpd 出新版的通知信,本來以為是 security fix,結果看了一下發現雖然版號是從 1.4.55 變到 1.4.56,但這個版本支援了 HTTP/2,以及 Brotli 壓縮:「Release-1 4 56 - Lighttpd - lighty labs」。

lighttpd 應該是我還在學校的時候幫 PIXNET 用的東西?他跑 FastCGI 模式接 PHP 當時效能還不錯... 現在自己架站的習慣是用 nginx 了。

反倒是他當年因為要更方便的支援 FastCGI 而生的 spawn-fcgi 讓 nginx 與其他專案沿用,後來是各家專案自己都原生支援 FastCGI 或是其他協定,所以重要性就淡了一些...

這次的更新推出的 HTTP/2 算是補上蠻重要的功能,不知道會對 lighttpd 社群帶來什麼能量...

BiglyBT 支援 BitTorrent v2

先前提到的「libtorrent 宣佈支援 BitTorrent v2」,BiglyBT 整合完了:「BiglyBT is the First Torrent Client to Support the BitTorrent V2 Spec」。

看了一下 BiglyBT 的介紹,主要是因為當初 https://en.wikipedia.org/wiki/Vuze 變成 adware 之後分支出來的:

BiglyBT is a feature filled, open source, ad-free, bittorrent client.

BiglyBT is the continuation of the Vuze/Azureus open source project first created in 2003, and is being actively developed by the original coders.

不過這是 Java 寫的 client,目前需求也不大,我自己應該還是會繼續等 qBittorrent 支援,看起來在這邊:「BitTorrent v2 #13344」,不過現在看起來沒什麼進展...

自己架設各種服務的 ansible playbook:Sovereign

來清個瀏覽器上的 tab,sovereign 是個 ansible playbook,幫你架設各種服務:

Sovereign is a set of Ansible playbooks that you can use to build and maintain your own personal cloud based entirely on open source software, so you’re in control.

裡面包了許多服務,但看下來比較麻煩的是郵件相關的服務,現在要自己搞一整包郵件系統一直都是痛點,這點在 Hacker News 上偶而就會看到分享...

這包 ansible playbook 裡面跟郵件相關的部份包括了 PostfixDovecot 搭出基本的 SMTP + IMAP + POP3,另外用 Solr (全文搜尋)、PostgreSQL (Virtual domain)、Rspamd (擋 spam),DKIMDMARC (郵件來源認證機制),以及 Roundcube (Webmail)。

非郵件相關的話包括了 VPN、cloud storage,以及一些管理、安全、備份有關的服務可以用,看起來的確是把常用的東西都放進去了。

不過這種東西自己架是有自己架的「樂趣」,而且對底層掌握度也比較高 (尤其是又有隱私與安全性的考量),對應的客群應該會看一看架構,然後自己動手?