Month: April 2024

Google 推出 Jpegli：JPEG 的 encoder 以及 decoder

在 Hacker News 上看到「Jpegli: A new JPEG coding library (googleblog.com)」，原文是「Introducing Jpegli: A New JPEG Coding Library」。

裡面是有提到檔案大小可以更小：

Our results show that Jpegli can compress high quality images 35% more than traditional JPEG codecs.

但這邊沒有講壓縮率的部分是哪個「traditional JPEG codec」比較，大概就是「WebP 的檔案大小未必比 JPEG 小...」這邊的老招了，應該是跟 cjpeg 比，如果跟 MozJPEG 比的話就未必有那麼高了。

想要寫起來的是 Hacker News 留言有提到命名的邏輯，這個 -li 結尾的用法可以看出來是 Google 蘇黎世團隊的產品：

The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.

This obviously comes out of Google Zürich.

這點還可以從其他的產品看到類似的命名，比較熟的是 Zopfli 以及 Brotli。

IEEE 也宣佈禁用 Lenna 圖了

Lenna (Lena) 是個經典的標準測試圖片，一方面是因為有很多細節可以觀察 image-related algorithm 的情況，另外一方面也是因為這張圖是取自 1972 年的 Playboy 雜誌：

Lenna (or Lena) is a standard test image used in the field of digital image processing starting in 1973, but it is no longer considered appropriate by some authors.

To explain why the image became a standard in the field, David C. Munson, editor-in-chief of IEEE Transactions on Image Processing, stated that it was a good test image because of its detail, flat regions, shading, and texture. He also noted that "the Lena image is a picture of an attractive woman. It is not surprising that the (mostly male) image processing research community gravitated toward an image that they found attractive."

也因為後者的原因，後來也有愈來愈多其他的圖片可以達到類似的效果 (甚至更好)，就有替代的聲音出現了。

另外一方面，Lena 本人在 2019 年也提到希望淡出的想法：「How a Nude “Playboy” Photo Became a Fixture in the Tech World」。

But I retired from modeling a long time ago. It’s time I retired from tech, too.

而最新的消息就是 2024/04/01 開始，IEEE 不再接受使用 Lenna 圖的投稿：「Institute bans use of Playboy test image in engineering journals」。

之後大概只會在歷史回顧的時候會引用提到了...

利用信件裡面的 CSS，讓文字只在轉寄後才出現

在「Kobold letters: HTML emails are a risk (lutrasecurity.com)」這邊看到的 security advisory (算... 是吧？)，原文在「Kobold Letters」這邊，如同標題寫的，方法其實意外的簡單...

Thunderbird 是透過 .moz-text-html>div> 指定就可以達到效果：

Outlook on the web (i.e. 雲端版本) 則是有在 id 上面增加隨機的 prefix 避免，但可以用 body>div> 避開，另外有些眉眉角角的地方會稍微複雜一點，但還是可行的：

而 Gmail 則是直接用個簡單的 css selector 掛上 display: none; 就 OK 了：在 sender 端 (轉寄者) 看不到，在 receiver 端則可以 (效果更好？)：

比較慘的是目前大家都沒有想到比較好的解法，就算這次提到的方法被補上了，應該還是很容易被繞過去：

Unfortunately, for the foreseeable future, it is sadly not realistic to expect email clients to implement robust mitigation. This means that it is up to the users to be aware of the dangers of HTML emails and to take the necessary precautions.

另外文章裡面提到了 Can I email 這個網站，看起來如果要自己處理 email 內容的話是個不錯的資源...

把 MIT license 當歌詞寫歌...？

在「AI-generated sad girl with piano performs the text of the MIT License (twitter.com/goodside)」這邊看到的推，把 MIT License 的條文當歌詞丟進去寫歌 (應該是最近很紅的 Suno.ai？)：

WTF...

下雨天才會通的網路

在 Hacker News 上看到「The Wi-Fi only works when it's raining (predr.ag)」，原文是「The Wi-Fi only works when it's raining」，基於文章的發表日期，雖然作者宣稱是 true story，但我還是沒辦法確定... 但內容還蠻有趣的：

Happy April 1st! This post is part of April Cools Club: an April 1st effort to publish genuine essays on unexpected topics. Please enjoy this true story, and rest assured that the tech content will be back soon!

文章裡面提到作者的老爸是工程師，他老爸自己開的公司跟家距離算近，所以他老爸用指向性天線，把公司的商用 internet 橋接到家裡用，用了十年都沒什麼問題，但最近幾個禮拜開始只有下雨天才會通？

這聽起來蠻反常的，下雨應該只會讓訊號更差才對...

直接跳到最後的揭曉，原因是鄰居的樹在這十年內長高擋到訊號了，而下雨天會讓植物稍微垂下來，於是下雨天時訊號就通了...

作者的解法則是升級設備，把本來 802.11g 的設備換成 802.11n 的設備，抗干擾的能力更好 (這邊應該是指 coding & 5GHz)：

We replaced our old 802.11g devices with new 802.11n ones, which took advantage of new magic math and physics to make signals more resistant to interference.

另外作者文章用的子標題應該是與 Five stages of grief 相關，不過文章裡是 Denial-Bargaining-Determination-Debugging-Realization。

台灣 3G 網路的停用：2024/06/30

在 iThome 上面看到的消息，三大電信業者都將在 2024/06/30 停止 3G 網路：「中華電信、遠傳、台灣大將在6/30前關閉3G網路，手機不支援VoLTE將無法通話」。

翻了一下 iPhone 的部分，從 2014 年九月推出的 iPhone 6 就支援 VoLTE 了，差不多快十年了；這樣 Android 陣營應該也是差不多的時間才對...

到時候可以看看 iPhone 5s 的訊號會是怎麼樣... (應該會是完全沒訊號？)

拿 WireGuard 當作 SOCKS5 Proxy 的用戶端

pufferffish/wireproxyHacker News 上看到「Wireproxy: WireGuard client that exposes itself as a HTTP/SOCKS5 proxy (github.com/pufferffish)」這個有趣的東西，GitHub 上的專案頁在 pufferffish/wireproxy 這邊：

A wireguard client that exposes itself as a socks5/http proxy or tunnels.

不需要連上完整版本的 WireGuard VPN，而是透過 proxy 協定讓使用者可以使用，這樣配合瀏覽器的工具 (像是 SwitchyOmega) 可以很方便的設定各種變化，像是針對日本限定的網站走日本的 VPS instance 出去。

另外值得一提的是，這是一個 userland 而且不需要 root 權限的實作；這點蠻容易可以理解的，只是聽一個 TCP port 然後用 WireGuard protocol 跟遠端溝通，的確是不需要 root 權限。

另外在 Hacker News 的留言裡面還看到了 aramperes/onetun 這個工具，看起來是 server 端的實作，支援 TCP 與 UDP：

A cross-platform, user-space WireGuard port-forwarder that requires no root-access or system network configurations.

這兩個看起來剛好可以搭在一起...？

Gitea 預定淘汰掉 jQuery + Fomantic-UI + Semantic-UI，改用 Tailwind CSS

在「So long jQuery, and thanks for all the fish」這邊宣佈了 jQuery 的退役計畫，會改用 Tailwind CSS：

We would like to celebrate the significant work done to remove a significant portion of jQuery in our codebase and the start of the switch to using Tailwind CSS.

We would also like to thank the creators and maintainers of jQuery, Fomantic-UI, and Semantic-UI which we have used for many years, and while the usage of these projects in Gitea will be going away, they have powered Gitea's interface for almost an entire decade.

不確定是不是一個好的方向，因為在這十年前端的「蓬勃發展」後，jQuery 其實比較起來變得非常輕量 (87KB，如果是 gzipped 後則是 30KB)，而且從一開始 John Resig 就很在意執行速度，不像現在各種 framework 都是抽象再抽象，沒在管效能的...

目前應該會在 Gitea 1.22 亮相，到時候可以看看改出來的結果...

Cloudflare Workers 支援 Python (是 open beta)

Cloudflare 宣佈 Cloudflare Workers 支援 Python：「Bringing Python to Workers using Pyodide and WebAssembly」。

不過比較特別的是，並不是原生支援 Python 環境，而是透過轉譯成 WebAssembly 丟進 V8 engine 執行，就如同文章標題提到的。

另外是套件的部分，照這個文字的說明，應該不是所有的套件都可以丟進去用 (can import a subnet of popular Python packages)，支援的套件看起來是預先 compile 好：

All bindings, including bindings to Vectorize, Workers AI, R2, Durable Objects, and more are supported on day one. Python Workers can import a subset of popular Python packages including FastAPI, Langchain, Numpy and more. There are no extra build steps or external toolchains.

看起來是打算全部都用 javascript 當作基礎？

UI Event 的順序

othree 寫了一篇「UI Event Order」在講滑鼠 (或是更廣廣義的 pointer 類) 以及鍵盤 (包括輸入法) 在瀏覽器上會產生的 event。

裡面有些是歷史 (提到 IE 上的實作方式)，現在都不太會碰到了，可以直接看目前的幾份標準就好，然後蠻多標準都還是在 draft 階段，各家瀏覽器更新的速度不一樣，所以會有不同的行為冒出來。

我決定先把文章保留起來，等遇到的時候再回來看 XD