便宜小主機的選擇

在「Low Cost Mini PCs (lowcostminipcs.com)」這邊看到有趣的 side project,作者從 eBay 上面掃出來的資料做成網頁直接可以選擇:「Low Cost Mini PCs」。

看原始碼可以看到直接把所有 item 都放進 html element,速度還蠻快的,我用 iPhone SE 3 開只要一秒鐘 (而且是 cold start,寫文章才想到用 iPhone 打開),比起很多搞「現代前端」的網站都快超多...

另外這讓我想到去翻 Intel 的規格網站,看一下這幾顆的差異:「Intel® Processor N200」、「Intel® Processor N100」、「Intel® Processor N97」、「Intel® Processor N95」。

其中 N97 是掛在 Embedded 區塊下的,而其他三顆都是掛在 Mobile 下,不過 N200 的 Embedded Options Available 是 Yes,不過意思跟想像的好像不太一樣:

“Embedded Options Available” indicates the SKU is typically available for purchase for 7 years from the launch of the first SKU in the Product family and may be available for purchase for a longer period of time under certain circumstances. Intel does not commit or guarantee product Availability or Technical Support by way of roadmap guidance. Intel reserves the right to change roadmaps or discontinue products, software and software support services through standard EOL/PDN processes. Product certification and use condition information can be found in the Production Release Qualification (PRQ) report for this SKU. Contact your Intel representative for details.

功耗標示上面,N200 與 N100 的 TDP 都是 6W,而 N97 到 12W,N95 則是到 15W。

如果把 N200 與 N100 抓出來比較,看起來 N200 的時脈可以衝高一點,然後內建的 GPU 強一些,但其他就沒什麼差異了,難怪 N100 變成新一代的小主機首選...

Elasticsearch 打算要回來提供 AGPL 授權

在「Elasticsearch is open source, again (elastic.co)」這邊看到的,Elasticsearch 目前是自家的 ELv2 以及 SSPL 授權,現在打算要提供 AGPL 授權了:「Elasticsearch is Open Source, Again」。

不過應該也不會回去用了,之前 Elastic 的大小動作太多,像是直接在新版 client SDK 上擋掉所有不是 Elasticsearch 的伺服器端 (所以 OpenSearch 就被擋了):「Elasticsearch error "The client noticed that the server is not Elasticsearch and we do not support this unknown product"」。

既然 OpenSearch 堪用就繼續用?反正在雲上面大多也都不是自己架,而是用現成的。

另外這幾年 PostgreSQL 上面做 fulltext search 的套件愈來愈多,也是個常用的方案?(量大的時候 read replica 拆出去就不太會影響到 main DB 效能)

AWSOpenSearch 看起來證明了換 license 對這些大公司沒什麼用,這些大公司有的是錢跟人可以 fork 出來自己搞... 所以想要一開始沾 open source 的名字不如一開始就用 AGPL?

2GB 版本的 Raspberry Pi 5

本來是沒什麼注意的,直到 Jeff Geerling 丟出測試提到同樣是 Raspberry Pi 5,2GB 版本的比起其他版本在 idle 狀態省了不少電才注意到:「New 2GB Pi 5 has 33% smaller die, 30% idle power savings」。

他拿了 4GB 與 8GB 的 RPi5 對比,可以看到 4GB 與 8GB 版本的耗電量沒有太大差異,反而是 2GB 版本有明顯的下降:

官方網站上面「Processors」這邊提到 BCM2712 這顆 D0 與 C1 的差異在於 D0 拿掉了沒有用到的功能 (當初自己研發這顆晶片的時候可能趕時間,從其他地方弄過來沒有整理?):

The D0 stepping of BCM2712 removes unused functionality from BCM2712C1. There is no functional difference between the C1 and D0 steppings. Physically, the packages use the same amount of space.

官方雖然提到 package 的大小一樣,但拆開封裝的外殼後發現 die 小了不少:

這對於被動散熱的系統算是個蠻大的改善,看起來就是少了 0.9W 左右,可以在全速運轉的狀態下持續更久才遇到過熱降速。

話說本來的 4GB 與 8GB 版本,如果庫存用完後應該也有可能換成這顆?

這個種類的機器拿來跑一些小東西還不錯... 像是 1GB RAM 的 Raspberry Pi 3 Model B 到現在都還是拿來跑 SmokePing 記錄家裡網路的狀況。

不過如果是想要在客廳有個小台的桌機的話,我還是推 Intel N100,一方面是記憶體多 (至少可以拉到 16GB RAM),另外一方面是 CPU 也快不少,然後 M.2 的 disk 通常是出廠的時橫就會提供,相容性不用管太多。

另外軟體上面除了 Linux 類的以外也可以選 Windows,對於家人要使用的門檻可能會低一些。

當然如果你真的對 Raspberry Pi 的 ecosystem 以及 GPIO 有很強烈的偏好的話又是另外一回事了,這個情況比較偏宗教信仰的邏輯:未必認同但是給予尊重。

陽交大資工 (原交大資工) 要退役 FreeBSD 伺服器了

結果是在 Plurk 上面看到 https://www.plurk.com/p/3g8a60cuxm 這則消息,原公告在「[重要事項]工作站系統升級維護及 FreeBSD EOL 規劃」這邊。

與 Linux 相關的是 alumni 工作站從 FreeBSD 換 Debian

alumni 工作站將由 Debian 系統取代。
現有的 alumni 工作站將於維護當天改名為 alumni1。
我們將提供三個月的遷移時間,alumni1 工作站將於三個月後停止服務。

而與 FreeBSD 有關的則是先縮減,然後三個月後停止服務:

將縮減至兩台工作站 bsd[1-2].cs.nycu.edu.tw
BSD 工作站將於三個月後停止服務。

雖然 alumni 主機只有偶而會連回去跑個 MTR 看各種 routing,但撤掉 FreeBSD 還是有點感傷啊。

不曉得現在 SA/NA 課程還有沒有在教 FreeBSD...

GNU Screen 5.0.0

Hacker News 上看到 GNU Screen 5.0.0 的消息:「GNU Screen 5.0 Released (savannah.gnu.org)」,官方網站是「GNU Screen v.5.0.0 is released」這邊。

從 source code 的下載頁面 https://ftp.gnu.org/gnu/screen/ 這邊可以看到上次 major version 的跳動 (從 3.9.15 跳到 4.0.0) 是 2004 年了,不過這次跳 5.0.0 不知道是什麼原因,從列出來的功能裡面是有看到不少 removed 的項目。

另外下載頁面上面最早只有 1995 年的檔案,這邊好像沒有所有的版本資訊;翻一下維基百科的 GNU Screen 條目,是個 1987 年誕生的軟體,比 CVS 還早 (1990 年出),當初的慣例都是一堆 patch 檔案傳來傳去 (比較小)。

當年剛接觸 FreeBSD 環境時開始學各種工具時學會的工具,記得當年還是各種 locale 百家齊放的時候還得自己 patch & compile 搞 Big5UTF-8 的轉換,

不過後來都跳到 tmux 了,雖然當年的 .screenrc 還留在 dotfiles 包裡面。

測試 Zen Browser

在「Zen, a Arc-like open-source browser based on the Firefox engine (zen-browser.app)」這邊看到 Zen Browser 的,主打個功能類似於先前很多用 Mac 的朋友有用的 Arc Browser,包括了 workspace 以及在側邊欄放 tab 的設計,不過我對這點反而不是很愛,主要是因為我的桌機螢幕是打直的,左右寬度只有 1200px 已經不太夠用了,tab icon 在左邊其實對於會更容易觸發 mobile view。

但選擇從 Firefox 改出來這件事情有吸引我,少數 Gecko engine 的瀏覽器。

安裝的方式除了一般下載以外,在 Linux 上有支援透過 Flatpak 官方的 repository 安裝,所以對於已經有在用 Flatpak 的人還蠻簡單的,裝起來後就是一堆個人化設定要做。

現在已知的是 font settings 的問題要解,不過這個是以前在用 Firefox 時就遇到的問題,所以應該只是跟過來的問題,得想辦法繞...

Google 提出的 GoogleSQL (Pipe 版本的 SQL 改良)

看到「SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL」這個研究投稿,PDF 檔案在 1004848.pdf 這邊。

Google 提出了 GoogleSQL 改善本來 SQL 的可讀性問題,另外也對 SQL optimizer 更有幫助。

直接拿 PDF 裡面的例子來說明,把本來是這樣的 SQL:

SELECT c_count, COUNT(*) AS custdist
FROM
  ( SELECT c_custkey, COUNT(o_orderkey) c_count
    FROM customer
    LEFT OUTER JOIN orders ON c_custkey = o_custkey
         AND o_comment NOT LIKE '%unusual%packages%'
    GROUP BY c_custkey
  ) AS c_orders
GROUP BY c_count
ORDER BY custdist DESC, c_count DESC;

變成這樣的:

FROM customer
|> LEFT OUTER JOIN orders ON c_custkey = o_custkey
AND o_comment NOT LIKE '%unusual%packages%'
|> AGGREGATE COUNT(o_orderkey) c_count
GROUP BY c_custkey
|> AGGREGATE COUNT(*) AS custdist
GROUP BY c_count
|> ORDER BY custdist DESC, c_count DESC;

可以看到這個語法除了變好讀以外,也指示了 SQL optimizer 怎麼去過濾與組合資料。

依照 Google 的說明,GoogleSQL 已經在許多 Google 的系統上實作了:

We’ve implemented pipe syntax in GoogleSQL, the SQL dialect and implementation shared across all1 SQL systems at Google including F1, BigQuery, Spanner and Procella, and the open-source release, ZetaSQL. GoogleSQL is a shared, reusable component, enabling many systems to share the same SQL dialect. This shared component allowed implementing pipe syntax in one place and then enabling it across many products.

裡面提到的 ZetaSQL 可以在 pipe-syntax.md 這邊看到。

我記得其他家也有類似的東西,PRQL 也是在解決類似的問題,不過語法走向不太一樣。

可以看看怎麼收斂...

找出並聯絡 AirPods 的失主

從「Did you lose your AirPods? (alexyancey.com)」這邊看到的,原文是「Did you lose your AirPods?」。

如同標題提到的,作者朋友撿到 AirPods,接上 iPhone 後能得到的資訊除了序號以外只有失主的電話末四碼了,不知道怎麼聯絡失主。

接下來作者開始想辦法,先假設失主是在同一個州,這樣電話的區碼 (前三碼) 就會一樣了,中間三碼的排列組合就只剩下 1000 組 (作者寫 999):

I started with the assumption that the owner lived near me in the Portland metropolitan area. With that, I restricted the search to our local area code*. Sure, they could be from out of town, but hey, let's give it a shot.

接著是透過公開的資料庫查有哪些電話號碼是有效,而且屬於行動網路的,這樣就降到 232 組:

Next, I narrowed it down by central office code (commonly called prefix) (those three digits after the area code). Most of Portland’s are assigned, but only 26% to wireless carriers. Also, 000-199 are reserved codes that aren't available for telcos. I lied earlier, sorry.

再接著,既然是 Apple 生態系的,作者決定用 iMessage Lookup API 去掃,這樣就剩下 84 組:

It's a safe bet that the owner has an iPhone with iMessage turned on. We can use this assumption to narrow down the list further by filtering out any non-iMessage phone numbers. I ran a check using this API. (The API is probably used for shady stuff, but my intentions were pure.)

最後是透過 MacBook 直接打 iMessage 出去問,就不用花錢透過簡訊聯絡:

With the list whittled down, I avoided Twilio entirely by using a script on my MacBook to send iMessages in bulk. Now we wait.

最後真的找到失主並且順利還給對方了:

回頭看裡面用到的兩個小技巧 (公開資料庫的查詢與 iMessage 的查詢),有蠻濃厚的 OSINT 味道,還蠻有趣的...

Android 規劃 16KB Page Size

Hacker News 上看到 Android 在規劃 16KB Page Size 的消息:「Adding 16 kb page size to Android (googleblog.com)」,原文是「Adding 16 KB Page Size to Android」。

Android 目前主力是 4KB Page Size,但因為 ARM 有支援 16KB Page Size,所以測試後發現雖然會多用 9% 記憶體,但效能會增加不少:

Most CPUs today support a 4 KB page size and so the Android OS and applications have historically been built and optimized to run with a 4 KB page size. ARM CPUs support the larger 16 KB page size. When Android uses this larger page size, we observe an overall performance boost of 5-10% while using ~9% additional memory.

雖然說 overall performance 有提升,但在「Benefits and performance gains」這邊可以看到目前列出來的項目都是特定的行為 (像是 app 啟動,camera 啟動,或是開機時間),這點可能要再看看其他的評測。

16KB Page Size 應該是個取捨,畢竟手機不像伺服器隨便就是上百 GB RAM 甚至到 TB RAM,跑一些吃記憶體的應用用 Huge Page 拉到 MB 等級的 Page Size 比較划算...

Telegram 的 CEO Pavel Durov 在法國機場被收押

好幾個地方都有報導 Telegram 的 CEO Pavel Durov 在法國的機場被收押的事情,引 Reuters 的好了:「Telegram messaging app CEO Durov arrested in France」。

目前傳言的理由是缺乏管理,允許犯罪行為:

TF1 and BFM both said the investigation was focused on a lack of moderators on Telegram, and that police considered that this situation allowed criminal activity to go on undeterred on the messaging app.

算是剛發生的新聞,接下來幾天應該會有後續的消息...