Tag: engine

GKE 在推廣拿 240.0.0.0/4 來當 Private IP 用

看到「Leveraging Class E IPv4 Address space to mitigate IPv4 exhaustion issues in GKE」這篇，GKE 在推 240.0.0.0/4 當作 Private IP 用，可以看到文章裡面一直在說 240.0.0.0/4 跑起來沒有什麼問題，也可以透過 NAT 連到 internet 上的其他服務...

看到想用 240.0.0.0/4 大概是 10.0.0.0/8 不夠用的概念，本來一開始腦袋閃過去是 65536 個 IP 不夠用 (心裡覺得「喔在 microservice 架構下公司大一點，把 container 開成這樣好像也合理」)，突然發現不對，10.0.0.0/8 是三個 256 的乘積，是 16M 個 IP address...

16M 的 IP address，如果一個 IP address 對應到一個 container，以 Google 在 2023 年全球有 182K 員工來看，平均下來每個員工可以開 87 個 container？(不能再多了？)

有這樣的概念後回頭讀這篇還蠻「有趣」的...

Automattic 與 WP Engine 打架中

請注意這邊是為了好理解的說明方式，時間線請自己對一下...

先用 Hacker News 這邊的背景說明當作開頭，在 id=41614406 這邊提到 WP Engine 的員工因為直接吐槽 WP Engine 的官僚不同意參與貢獻 WordPress (但先前有公開講會參與貢獻) 而被 fire：

It looks like people here are missing the context of the source of the issue between Matt and WP engine. Couple days ago he posted on X that wpengine has similar revenue to automattic, yet doesn’t contribute back to open source as much as they promised to (5 hour per week per employee or something like that). A wpengine employee replied to a post saying that management doesn’t allow them to contribute to WordPress open source because it doesn’t align with KPI targets. That employee got fired the next day. That’s when Matt’s issue with wpengine escalated.

另外的資訊是 Matt Mullenweg (WordPress 的專案發起人，以及 Automattic 的 CEO) 發了「WP Engine is not WordPress」這篇，接著是 WP Engine 發了 C&D letter 給 Automattic，然後也公告 X (Twitter) 上：

事情還在發展中，預期會有更多戳來戳去的情況。不過記得這畢竟是商業公司的互戳，雙方鐵定只會挑自己有利的講，不用太早下結論... 拿著爆米花桶看就好。

Google 移除網頁存檔 Google Cache

在 Hacker News Daily 上的整理看到的：「Google Cache Is Fully Dead」。

這樣的話變成只有 Internet Archive 與 archive.today 可以用了。

Google Cache 之所以重要是因為 Google 搜尋更新的速度很快，尤其是針對比較大的站台，另外因為搜尋引擎拉資料是自動化的，在文章剛被刪除的當下可能連 Internet Archive 或是 archive.today 都還沒有人去存，這時候至少還可以去 Google Cache 上面拉一份出來。

但拔功能已經是 Google 的常態了，現在只是列表上面多了一項...

IEC 60320 C5 的接頭：米老鼠頭

前陣子從日本買的電器附的線是兩孔加地線，與 IEC 60320 C5 的頭：

雖然我手上剛好有 Panasonic WH 2881P 可以把地線硬接起來：

但想了想既然是標準接頭，弄一條新的線好像比較好，所以就在網路上找，結果發現都找不到... 本來想說是不是台灣沒在用這種頭，但後來想到很多筆電好像就是用這種頭？

多花了一些時間找資料，後來看到維基百科上面這樣寫：

許多用於筆記本電腦的小型開關模式電源。由於其形狀，通常稱為「三葉草」或「米老鼠」連接器。

改用「米老鼠 電源線」就出現一堆，苦啊...

測試 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 時就遇到的問題，所以應該只是跟過來的問題，得想辦法繞...

Reddit 的 robots.txt 要求阻擋所有機器人

在「Reddit's Robots.txt Changed (reddit.com)」這邊看到的，可以看到現在 https://www.reddit.com/robots.txt 的內容變成 (刪掉註解的部分)：

User-agent: *
Disallow: /

這個改變倒是沒預料到的... 來觀察看看 HN 上後續的討論？

Google 承認搜尋引擎內部 API 文件洩漏了？

前幾天很熱門的「An Anonymous Source Shared Thousands of Leaked Google Search API Documents with Me; Everyone in SEO Should See Them」消息，裡面提到有拿到一份疑似 Google 搜尋引擎的內部 API 文件， 可以證實有很多 Google 搜尋引擎的運作與 Google 對外宣稱的不符。

作者找了業內人士幫忙分析 (他自己說他先前也在碰 SEO 這塊，但是已經離開這個行業六年了)：

Next, I needed help analyzing and deciphering the naming conventions and more technical aspects of the documentation. I’ve worked with APIs a bit, but it’s been 20 years since I wrote code and 6 years since I practiced SEO professionally.

包括作者的一些 Google 朋友，或是 ex-Googler 都確認這份文件符合 Google 內部的文件規範要求，另外裡面的元素編排也都很像是 Google 的文件。

本來以為事情大概就這樣，後續應該就是會有很多人從這份文件分析 Google 有哪些 SEO 的偏好，找出哪些東西與 Google 宣稱的不符。

不過事情突然有個意外的轉折，Google 本來一直是「拒絕評論」的態度，但突然承認這份文件的確是他們內部文件：「Google confirms the leaked Search documents are real」。

"We would caution against making inaccurate assumptions about Search based on out-of-context, outdated, or incomplete information," Google spokesperson Davis Thompson told The Verge in an email. "We’ve shared extensive information about how Search works and the types of factors that our systems weigh, while also working to protect the integrity of our results from manipulation."

反正也沒有人會相信 outdated 了，但可以預想的是 Google 的搜尋結果應該又會變差，因為會有更多 SEO 垃圾開始想辦法衝排名上去...

用 udm=14 拿掉 Google Search 的一堆附加功能

在「&udm=14 | the disenshittification Konami code」這邊看到的，裡面有提到「How I Made Google’s “Web” View My Default Search」這篇說明。

我測了一下「how many people in the earth」這個搜尋條件，結果是這樣 (w/ uBlock Origin)：

加上 &udm=14 後會拿掉很多「輔助」的區塊：

有些人可能偏好前者，但有些人偏好後者，可以自己選擇... (不過我應該會繼續用 Kagi)

Reddit 當初對 Google 搜尋引擎的客製化設計

在 Hacker News 上看到的討論，裡面剛好有 Reddit 第一個雇用的工程師，Jeremy Edberg 的留言：「Reddit is taking over Google (businessinsider.com)」。

在 id=40068381 這邊提到了不少東西，首先是把 title 放進 url 裡面的作法：

To this day, my most public contribution to reddit is that I wrote the code to put the title of the post in the URL. That was done specifically for SEO purposes.

這個在 Google Webmasters (現在叫做 Google Search Console) 也針對 Reddit 處理，將速率強制設為 Custom，不讓 Reddit 的人改：

It was pretty much the only SEO optimization we ever did (along with a few DOM changes), because shortly after that, Google basically dedicated engineering effort specifically to crawling reddit. So much so that we lost the "crawl rate" button in our SEO admin page on Google, it was just set to "Custom".

後續還要針對 Google 的抓取在 load balancer 上把流量拆開處理，不然 crawling pattern 與一般使用情境很不一樣，會造成 cache 的效率極度低落：

I had to stand up a fleet of app servers and caches and databases, and change the load balancers so that Google basically had their own infrastructure (although we would shunt all crawlers there). Crawler traffic was very different than regular traffic -- it looked at pages more than two days old, something humans rarely did at the time. It would blow out every cache (memory, database, disk, etc.). So we put them on their own infra to keep them from killing the rest of the site.

這些算是頗有趣的經驗？

tf-idf 與 BM25

tf–idf 與 BM25 是兩個在資訊檢索 (IR) 裡面的經典演算法，也常被用在搜尋引擎技術上。

前陣子在練 Go，剛好找個主題來練，tf-idf 已經很熟了，但 BM25 沒有實際寫過，而自己的 blog 也累積了七千多篇，這個數量還算好用，不用自己另外 dump 維基百科的文章跑... (而且量太大)

第一步是拆成 token，我這邊就拿 bigram 拆了，但英文的部分把一整個詞當作一個單位，而非一個字母一個字母拆。

btw，這邊 tf-idf 與 BM25 的公式就請大家自己去維基百科上翻了...

tf-idf 概念上很簡單，而也沒有什麼 magic number 在公式裡面。

如果把 tf-idf 當一個 function 來看的話會是 score = tfidf(w, d, D)，表示一個字 w 在一份文件 d 裡面的分數 (而 D 是所有文件)。

而 tf 只跟文件本身有關，可以預先算好放著，df 在後續文件新增刪除時都可以 incremental update，不需要重頭算，是個對於平行化運算很友善的演算法。

接著是看 BM25，如果把 BM25 當作一個 function 來看的話，會是 array = bm25(Q, D)，針對 query words Q 與所有文章 D 傳回一個排序結果 array，裡面會是排序過的 document id，通常會包括分數。

而從公式可以看到 BM25 其實就是把 Q 裡面的每個字丟進 tf-idf 後加起來的變形，只是多考慮到文件大小對分數的影響，另外裡面引入了一些花招，像是 k1 與 b 這兩個常數項。

所以我就寫了兩個版本，一個是單純用 tf-idf 相加 (這樣長文章分數應該會比較高)，另外一個是用 BM25 的公式跑... 算是趣味趣味的寫法。

算是清掉了之前一直放著的項目...