長距離的 WiFi 科技 (背景：烏克蘭網路)

在 Hacker News 上的「Ask HN: What's with the DIY state of the art long-range Wi-Fi?」這篇開頭，嘗試找出低成本且 scalable 的方式重建戰爭時期烏克蘭的網路。

發文的人想要透過一般民用的 WiFi 設備達到長距離 (這邊指的是遠超過 WiFi 設計時的距離，5～20km)，但不用很快的網路 (大概 0.1～1Mbps)：

The idea is to make a single device that can act as both a relay station, as well as an actual hotspot, it then can be placed in line-of-sight configuration to potentially cover huge areas (the accepted performance would be anywhere from 0.1-1 Mbit/s point-to-point over anywhere from 5-20km.

然後成本要夠低，希望壓在每組 US$100 的範圍：

We are aiming to bring the cost of such configuration down to $100 per unit at least.

後面的討論裡面有提到幾個社群有在建立分散式網路，一個比較知名的是德國的 Freifunk，從「Find your nearest community」這邊用節點數量排序可以看到最大的社群超過 4000 個節點，另外有兩個主流的技術處理 routing 的問題，一個是 batman-adv，另外一個是 802.11s。

另外找資料的時候有發現維基百科也有頁面在介紹這個技術：「Long-range Wi-Fi」，另外這個主題也是國外一些科技 YouTuber 喜歡拍的，像是 Linus Tech Tips 之前用 UI 的設備在視線可直視的 12km 距離下跑過 100+Mbps 的速度：

這樣似乎是可以預期一般的硬體刷機加上指向性天線，是有機會達到前面提到的要求...

用 AI 模型判斷是否為 AI 產生的文字

OpenAI 放出了新的 model，可以用來判斷是否為 AI 產生的文字：「New AI classifier for indicating AI-written text」。

但目前的成效其實還是不太行，只以英文的成效來看，true positive 只有 26%，而 false positive 是 9%：

In our evaluations on a “challenge set” of English texts, our classifier correctly identifies 26% of AI-written text (true positives) as “likely AI-written,” while incorrectly labeling human-written text as AI-written 9% of the time (false positives).

另外也有提到弱點，像是比較短的內容機很難辨認：

The classifier is very unreliable on short texts (below 1,000 characters). Even longer texts are sometimes incorrectly labeled by the classifier.

然後就是有正確答案的內容也很難辨認，因為正確答案幾乎都是一樣的：

Text that is very predictable cannot be reliably identified. For example, it is impossible to predict whether a list of the first 1,000 prime numbers was written by AI or humans, because the correct answer is always the same.

另外題到了技術上的限制，現在的方法比較像是「辨認是不是從某些 corpus 訓練出來的 model，所產生的文字」，而非通用性的 AI 文字偵測：

Classifiers based on neural networks are known to be poorly calibrated outside of their training data. For inputs that are very different from text in our training set, the classifier is sometimes extremely confident in a wrong prediction.

看起來是還不到可以用的程度...

Twitter 宣佈要廢掉免費的 API 權限

昨天下午的時候看到這則官方在 Twitter 上提到的消息，要廢掉 free tier 的 API access：

但這邊提到的 paid basic tier 的價錢還沒看到公告。以「API Pricing - It’s very dark out here」這邊看到的價格，目前的 premium plan 超級貴：

這下看起來是真的得搬了，目前有好幾隻程式在上面跑 :o

OpenAI 推出 ChatGPT Plus

OpenAI 提出了 ChatGPT 的付費方案：「Introducing ChatGPT Plus」。

目前只開美國：

ChatGPT Plus is available to customers in the United States, and we will begin the process of inviting people from our waitlist over the coming weeks. We plan to expand access and support to additional countries and regions soon.

公告的價錢是 US$20/mo，基本上就是保證使用權。這跟之前有傳言 US$42/mo 叫 Professional 的方案低了不少：「ChatGPT users report $42 a month pricing for ‘pro’ access but no official announcement yet」：

The new subscription plan, ChatGPT Plus, will be available for $20/month, and subscribers will receive a number of benefits:

  • General access to ChatGPT, even during peak times
  • Faster response times
  • Priority access to new features and improvements

應該是會訂起來用，光是現在 free tier 就已經找到一些常用的模式，可以省下不少時間...

Mac 會自己改變 Desktop 位置的問題

以前好像沒遇過，換了 M1 以後才注意到 desktop 位置位自己被改變，覺得很阿雜... 找了資料才發現是個 "feature"：「How to prevent Mac from changing the order of Desktops/Spaces」。

關掉就好了，網路上的資料最早出現在 2018 年左右，大概是那個時候被加進去的？

Yahoo! 要重新搞搜尋引擎？

看到 Hacker News 上提到 Y! 要重新搞 search engine 的消息：「Yahoo is making a return to search」，HN 上的討論在「Yahoo is making a return to search (searchengineland.com)」這邊。

跡象包括了招募資訊與 Twitter 帳號 @YahooSearch 的重啟，還有 LinkedIn 上一些 Y! 的高層公開提到這次的招募。

現在的 Yahoo! Search 應該是 Bing 的資料 (很久沒有聽到新的消息了)，至少從維基百科上面看到的說明提到 2019/10 後就又跳回 Bing 了：

As of October 2019, Yahoo! Search is once again powered by Bing.

這樣可以讓市場再多一點變化？

Content Defined Chunking (CDC)

前幾個禮拜在 Hacker News Daily 上看到「CDC File Transfer (github.com/google)」這則，連結是指到 Google 的 GitHub 專案上，裡面實做了 FastCDC 演算法，另外說明他們為什麼要解這個問題以及對應的成果：「google/cdc-file-transfer」。

Google 的人看起來像是是在 CI/CD 階段遇到頻寬上的問題 (從「The builds are 40-45 GB large.」這邊猜)，用 scp 與 rsync 看起來都不能解，所以他們自己刻了 FastCDC 演算法來解。

但我對 Content Defined Chunking (CDC) 不熟，所以先查一下 CDC 是什麼東西，就查到 restic 這篇講得很清楚：「Foundation - Introducing Content Defined Chunking (CDC)」。

要計算 delta 很直覺的作法就是要切 chunk，而接著的直覺就是固定大小的 chunk 切開，像是這樣每 16 bytes 切一個 chunk：

0123456789abcdef 0123456789abcdef 0123456789abcdef 0123456789abcdef

如果其中一個地方有變化，但其他沒變化的話就可以透過 cryptographic hash function (像是 SHA-256) 確認 chunk 內容一樣，進而省下很多傳輸的頻寬：

0123456789abcdef 0123456789ABCDEF 0123456789abcdef 0123456789abcdef

但可以馬上看出來這個方法的大缺點是只能處理 replacement，很難處理 insert & delete 的部份，舉例來說，如果變更是在開頭的地方加上 ABC，就會造成 chunk 會完全不一樣，而導致全部都要再傳一次：

ABC0123456789abc def0123456789abc def0123456789abc def0123456789abc def

這邊其實是個經典的演算法問題：想要找出兩個 string 的差異 (把舊的內容當作一個 string，新的內容也當作一個 string)。

這個問題算是 Edit distance 類型的題目，但你會發現解 Edit distance 的演算法會需要先傳輸完整個 string 才能開始跑演算法，這就本末倒置了。

而另外一個想法是，放棄固定的 chunk 大小，改用其他方式決定 chunk 的邊界要切在哪裡。而 CDC 就是利用一段 sliding window + hash 來找出切割的點。

文章裡面提到的 sliding window 是 64 bytes，這邊就可以算出對應的 HASH(b0, b1, ..., b63)，然後往右滑動變成 HASH(b1, b2, ..., b64)，再來是 HASH(b2, b3, ..., b65)，一直往右滑動計算。

接下來 restic 會看 hash 值，如果最低的 21 bits 都是 0 就切開，所以 chunk 大小的期望值應該是 2MB？(這邊不確定，好像不能直接用 2^21 算，應該用積分之類的方法...)

For each fingerprint, restic then tests if the lowest 21 bits are zero. If this is the case, restic found a new chunk boundary.

而這個演算法可以適應新增與刪除的操作，不會造成從新增或刪除後的資料都要重傳，只有自己這個 chunk 需要重傳 (可能前或後的 chunk 也會要)。

然後挑一下 hash function 的特性，就可以讓計算的速度也很快。這邊提到了 hash function 可以用 Rolling hash，可以很快的從 HASH(b0, b1, ..., b63) 算出 HASH(b1, b2, ..., b64)，而不需要全部重算。

有了 chunk 後，再用 cryptographic hash function 比較 chunk 的內容是否一樣，這樣就可以大幅降低傳輸所需要的頻寬了。

瑞士最大的線上購物平台 Digitec Galaxus 公開維修相關資訊

前幾天的 Hacker News 上看到的消息：「Refreshingly honest – Digitec Galaxus now displays warranty score and return rate」，瑞士最大的線上購物平台 Digitec Galaxus 決定公開維修相關的資訊，討論在「Digitec Galaxus now displays warranty score and return rate (galaxus.ch)」這邊可以看到。

從文章裡面可以看到說明的圖片，主要是公開了一些數字，第一個是 return rate (退貨率)：

再來是故障的資訊：

然後是維修時間：

這邊隨便抓了「ASUS ROG Strix GeForce RTX 4070 Ti OC Edition」這個看，可以看到這三個資訊：

另外在 Hacker News 討論裡面看到一些有趣的資訊，像是歐盟強制降價需要提供至少三十天價錢的歷史記錄 (但要注意瑞士不是歐盟成員國)：

This is now a law enforced in European Union to display such history (at least the lowest price in last 30 or more days so customer knows if the price was not fake rised just before lowering it and calling it a sale). WooCommerce has a plugin for that now.

搜尋後可以找到應該是出自「EUR-Lex - 52021XC1229(06) - EN - EUR-Lex」這邊的 Article 6a：

1. Any announcement of a price reduction shall indicate the prior price applied by the trader for a determined period of time prior to the application of the price reduction.

2. The prior price means the lowest price applied by the trader during a period of time not shorter than 30 days prior to the application of the price reduction.

3. Member States may provide for different rules for goods which are liable to deteriorate or expire rapidly.

4. Where the product has been on the market for less than 30 days, Member States may also provide for a shorter period of time than the period specified in paragraph 2.

5. Member States may provide that, when the price reduction is progressively increased, the prior price is the price without the price reduction before the first application of the price reduction;

台灣的話因為沒有法令強制，目前需要透過第三方服務去追，像是 twbuyer.info 之類的服務，但就只有大平台才有提供了。

Vultr 開大阪機房

Vultr 宣布開大阪機房：「New Cloud Data Center Location: Osaka, Japan」。

本來的東京機房從 HiNet 過去會塞，可以看到每天都會有一段時間 latency 會飄起來：

從 HiNet 過去 Vultr 東京機房是走 PCCW 的線路：

從 Vultr 東京機房回來是走 NTT 的線路：

如果是 Vultr 大阪機房的話，先用 mtr 看了一下 latency，狀況似乎是好很多？好像可以考慮把東京的機器搬到大阪看看...

iPhone 5S 又拿到安全性更新了：iOS 12.5.7 (2023/01/23)

Apple 又針對 iOS 12 釋出安全性更新了：「About the security content of iOS 12.5.7」。

Available for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.1.

Description: A type confusion issue was addressed with improved state handling.

這次的更新是 backport 去年十二月在 Safari 16.2 上修正的 CVE-2022-42856：

A type confusion issue was addressed with improved state handling. This issue is fixed in Safari 16.2, tvOS 16.2, macOS Ventura 13.1, iOS 15.7.2 and iPadOS 15.7.2, iOS 16.1.2. Processing maliciously crafted web content may lead to arbitrary code execution.

所以這包跟上次一樣 (參考先前寫的 「iOS 12.5.6」這篇)，也是在修正 RCE 類的漏洞，這樣對於 iPhone 5S 等於是進入第九年的支援了。

之前在網路上有看到有人在猜是因為海外有很多異議人士拿這隻手機，所以美國政府「希望」Apple 能夠針對一些高危險性的安全漏洞提供更新？