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)」這則,連結是指到 GoogleGitHub 專案上,裡面實做了 FastCDC 演算法,另外說明他們為什麼要解這個問題以及對應的成果:「google/cdc-file-transfer」。

Google 的人看起來像是是在 CI/CD 階段遇到頻寬上的問題 (從「The builds are 40-45 GB large.」這邊猜),用 scprsync 看起來都不能解,所以他們自己刻了 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 能夠針對一些高危險性的安全漏洞提供更新?

GitHub 宣佈將在 2024 移除對 Subversion 支援

GitHub 從 2010 年的愚人節時宣佈支援 Subversion:「Announcing SVN Support」,雖然是愚人節的功能,但這個功能是會動的。

而這個功能出現十多年後,可以預期用的人愈來愈少。前幾天 GitHub 宣佈將在大約一年後的 2024/01/08 停止支援 Subversion:「Sunsetting Subversion support」。

然後在 Hacker News 上的討論「GitHub Sunsetting Subversion Support (github.blog)」則是直接讓 Scott Chacon (GitHub co-founder,同時也是第一篇公告文的作者 + 這個功能的兇手之一) 出來解釋當初搞出這個東西的前因與後果,還有一些感想。

裡面有提到這個功能當初推出來的時候是個好玩的性質,但意外的在上線後發現也讓一些老系統可以比較容易轉移:也就是讓 developer 可以先開始用 Git,但 CI 類的工具可以先不用改。

As one of the GitHub cofounders and the brainchild of this particular feature, I want to let everyone know that this is maybe the funniest thing I've ever done.

We released this feature and published the announcing blog post, on April Fool's Day, 2010. I remember demoing it to the other GitHub guys and saying how funny it would be if we made this an April Fool's day post as though it was a big stupid joke but then it actually completely worked on every repository we had and we all thought it would be great. Until nobody believed us. Which in hindsight we should have seen coming, since that was the joke, but nobody actually tried it. Then people tried it and it worked and they thought it was a trick or something.

It was really helpful for people migrating from legacy SVN based systems to us (CI and stuff) but I'm surprised to some degree that it's still running 13 years later when nobody is really facing that issue anymore. And I'm still undecided if the joke was worth the massive confusion it caused. But if I'm pressed, I would say that I would 100% release it on April Fool's Day again.

不過想要拔掉這個功能的起因不知道是什麼,技術債不知道有多少...

SQLite 的 HC-tree 計畫

Hacker News 首頁上看到的新計畫:「HC-tree is an experimental high-concurrency database back end for SQLite (sqlite.org)」,SQLite 弄了一個實驗性質的 backend,叫做 HC-tree

The HC-tree (hctree) project is an attempt to develop a new database backend that improves upon regular SQLite as follows:

他列了幾個重點,其中「Improved concurrency」這點題到了可以讓多個 writer 同時寫入運作,這點算是 SQLite 很大的改變,目前希望可以做到在 single-threaded 情況下不輸現有的 SQLite:

An implicit goal is that hctree must be as fast or faster than stock SQLite for all single-threaded cases. There is no point in running dozens of concurrent writers if each of them is an order of magnitude slower than a single writer writing to a legacy database.

另外一方面,這算是 SQLite 真正要面對資料庫的 isolation 的問題了,比起現在的版本,同時間從只有一個 writer 的架構要變成支援多個 writer 的架構,所以在「Concurrency Model」這邊也帶了一下他預期可以做到的事情。

然後這邊可以看到在解釋裡面有提到 table 與 index 還是 b-tree,這樣應該可以猜測 hctree 的實做方式應該還是在市場上已經很成熟的 MVCC 那套方法:

If no other client has modified any b-tree (table or index) entry or range that the transaction being committed accessed by a range or stabbing query, then the transaction is valid.

另外一個蠻大的改變是「Support for replication」,現有的 SQLite 可以透過 extension 的方式加掛支援 replication 功能,現在則是讓底層的 backend 直接支援。

底層支援新的 backend 以後看起來會有不少變化可以玩,第一個想到的當然是變成 server 類型的服務,也就是像 MySQL 或是 PostgreSQL 這樣的方式,另外一種方向是包裝成 distributed database,讓應用程式可以簡單跨機器使用。

目前還不知道會往什麼方向走就是了,也有可能 SQLite 這邊只實做 backend,上面讓大家發揮...

在單色 LCD 上面利用 PWM 產生灰階的效果

Hacker News 上看到「Grayscale on 1-bit LCDs (2022) (zephray.me)」這篇,原文在「Grayscale on 1-bit LCDs」這篇,講在單色的 LCD (黑白的 LCD) 上利用 PWM 的方式來模擬出灰階的效果。

文章蠻有趣的,可以看到他一直在 tune,想辦法做出更多階的灰階效果:

不過其實更有趣的事情是在 Hacker News 的留言裡面,有人起手式就放大招:

My father Bryce Bayer studied this question fifty years ago at Eastman Kodak; his approach is known as ordered dithering:

https://en.wikipedia.org/wiki/Ordered_dithering

One is effectively posterizing a grayscale image, and his primary goal was to reduce artifacts drawing unwanted attention to the borders between poster levels.

With improvements in hardware other approaches to dithering took over. The last time I saw my father's pattern was on a DEC box logo. He moved to the color group at Kodak, and designed the "Bayer filter" used in digital cameras.

不只是提到大名鼎鼎的 Bryce Bayer,開頭直接就 "My father Bryce Bayer ..."。

搜了一下 syzygies 這個用戶名稱,看起來像是 Bryce Bayer 的兒子 Dave Bayer (維基百科也有條目:Dave Bayer)。

GNU Make 在 4.4 引入的 --shuffle

Hacker News 首頁上看到的,作者送了一個提案到 GNU Make,後來被採用,在 4.4 版引入了 --shuffle 指令:「New make --shuffle mode」。

這個功能主要是想要找出在 Makefile 裡面沒有被定義好,平常是因為 side effect 而沒有出錯的地方。

像是作者就發現 libgfortran 沒有把 libquadmath 放到 dependency 的問題:

For example gcc’s libgfortran is missing a libquadmath build dependency. It is natural not to encounter it in real world as libquadmath is usually built along with other small runtimes way before g++ or gfortran is ready.

他的基本想法是把 target 的順序打亂掉,也就是在有指定 --shuffle 時,不一定會照 a -> b -> c 的順序往下遞迴,而可能會是 c -> b -> a 或是其他的順序:

all: a b c

這樣對於抓那些在 -j 平行編譯時會出包的套件也很有幫助,不需要在 -j 開很大的情況下才能重製問題,而是平常就有機會在 CI 環境下被抓出來。