各家首頁 JavaScript 的大小

看到「JavaScript Bloat in 2024 (tonsky.me)」這篇在講各家首頁 JavaScript 的大小,原文在「JavaScript Bloat in 2024」這邊。

作者 Nikita Prokopov 創造了很多 open source project,我比較有印象的是 Fira Code,這篇比較像是他在抱怨現在的網站...

裡面站台一堆都是 10MB+ 的 JavaScript 在跑的,突然提到 P 站只有 1.4MB 的時候笑了出來 (在 Hacker News 的 comment 裡面也有人提到這個):

Compare it to people who really care about performance — Pornhub, 1.4 MB:

另外 Jira 也被拿出來鞭:

Here, Jira, a task management software. Almost 50 MB!

但趨勢看起來不可逆?現在開發網站一堆都搞前後端分離,用 JavaScript 產生出所有頁面,然後再想辦法補 SEO...

從 Backblaze 的年度報告裡看 HGST 的 4K 盤的問題

Backblaze 照慣例放出了年度報告,這次是 2023 年整年的回顧:「Backblaze Drive Stats for 2023」。

樣本數量少的跳過,這次比較特別的是可以發現 HGST 這邊 HUH721212ALN604 這顆樣本數破萬,而且 AFR 高到 3.69% 了:

他上面那顆 HUH721212ALE604 只差了一個字母 (N -> E),AFR 只有 0.95%,這個差距有點大。

拉了 datasheet 來確認:「Data Sheet: Ultrastar DC HC520 (He12)」,可以看到兩顆的規格幾乎一模一樣,唯一的差別是:

Format: Sector size (bytes)
4Kn: 4096
512e: 512

另外可以從「How to Read the Ultrastar Model Number」這邊看到 4Kn 與 512e 的說明:

E6 = 512e SATA 6Gb/s,
N6 = 4Kn SATA 6Gb/s

文章裡面沒有看到討論到這點,但好像很值得研究一下...?

iCloud 空間計算不準確的問題

記錄一下有這個現象,在 Hacker News 上看到的「Cleaning up my 200GB iCloud with some JavaScript (andykong.org)」,原文是「iCloud Cleanup」。

裡面提到 iCloud Photos 無法依照大小排序的問題,所以自己寫了一段 js code 解決。

想要記錄的是這段,文章後段有提到空間計算很不準確的問題:

So iCloud says the video is 128MB, I download it and the video is actually 48MB, and my free storage increases by ~170MB when I deleted it. Interesting!

以及發現愈舊的檔案吃的空間愈多,甚至到七倍:

It's weird that my storage freed up more than 7x the removed files size, and weirder still that old, big videos appear to have a much larger storage footprint in iCloud than in real life.

這不知道後續會不會跑出訴訟案?

估算 YouTube 影片總量的方式

Hacker News Daily 上看到「How big is YouTube? (ethanzuckerman.com)」這篇,原文在「How Big is YouTube?」。

算是個老問題了,而且應該是統計學上比較簡單的方法。先列出作者最後的成果:「TubeStats」。

作者用的方法是觀察 YouTube 的 vid:

Here’s how this works: YouTube URLs look like this: https://www.youtube.com/ watch?v=vXPJVwwEmiM

可以分析出來 vid 包括了 64-bit 的資訊,這個資料型態對工程師來說,看起來就很像是 uniformly distributed:

That bit after “watch?v=” is an 11 digit string. The first ten digits can be a-z,A-Z,0-9 and _-. The last digit is special, and can only be one of 16 values. Turns out there are 2^64 possible YouTube addresses, an enormous number: 18.4 quintillion. There are lots of YouTube videos, but not that many. Let’s guess for a moment that there are 1 billion YouTube videos – if you picked URLs at random, you’d only get a valid address roughly once every 18.4 billion tries.

然後就是隨機去產生 vid 去掃,這個方法跟 drunk dialing 的行為很像,算是 random sampling 的方式:

We refer to this method as “drunk dialing”, as it’s basically as sophisticated as taking swigs from a bottle of bourbon and mashing digits on a telephone, hoping to find a human being to speak to. Jason found a couple of cheats that makes the method roughly 32,000 times as efficient, meaning our “phone call” connects lots more often. Kevin Zheng wrote a whole bunch of scripts to do the dialing, and over the course of several months, we collected more than 10,000 truly random YouTube videos.

另外在 2011 年就有提出來利用 autocomplete 機制去算:

By comparing our results to other ways of generating lists of YouTube videos, we can declare them “plausibly random” if they generate similar results. Fortunately, one method does – it was discovered by Jia Zhou et. al. in 2011, and it’s far more efficient than our naïve method. (You generate a five character string where one character is a dash – YouTube will autocomplete those URLs and spit out a matching video if one exists.) Kevin now polls YouTube using the “dash method” and uses the results to maintain our dashboard at Tubestats.

目前他們的預估大約是 13B 左右的影片,換算大約是用掉 33.63 bits 了 (233.6):

In our case, our drunk dials tried roughly 32k numbers at the same time, and we got a “hit” every 50,000 times or so. Our current estimate for the size of YouTube is 13.325 billion videos – we are now updating this number every few weeks at tubestats.org.

而這邊提到的 32768 * 50k 會中一次的部分,這邊的大約是 30.61 bits,這樣加起來是差不多 64 bits 沒錯。

不過要注意的是,他們沒有給出 interval,所以 13B 的上下可能是一倍左右的差距 (6.5B~26B 之類的),這邊的數字當作概念比較好...

CloudFront 支援 4096-bit RSA 的 SSL/TLS certificate 了

CloudFront 總算支援 4096-bit 的 RSA SSL/TLS certificate 了:「Amazon CloudFront now supports 4096-bit RSA TLS certificates」。

翻了一下 AWS ACM,看起來是 2020 年以前就支援 4096-bit RSA SSL/TLS certificate 了,CloudFront 晚蠻多的...

另外查了一下目前的強度,NSA 給出 2048-bit RSA 對到 112-bit strength,而 3072-bit RSA 對到 128-bit strength;至於 4096-bit RSA,目前是估算大約在 140-bit strength,有點微妙的數字。

看起來主要應該是給 compliance 需求使用的,有些舊的 library 未必支援 ECC 類的演算法,還是得透過拉高 RSA key size 來增加安全性。

Windows 11 瘦身版本的 Tiny11

Tiny11NTDEV 弄出來的精簡版 Windows 11:「De-Bloated Windows 11 Build Runs on 2GB of RAM」。HN 上對應的討論在「De-Bloated Windows 11 Build Runs on 2GB of RAM (tomshardware.com)」。

It just uses around 8GB of space compared to the 20+GB that a standard installation does.

但有些限制,像是安全性更新需要自己來:

This OS install “is not serviceable,” notes NTDev. “.NET, drivers and security definition updates can still be installed from Windows Update,” so this isn’t an install which you can set and forget.

另外像是透過 WinSxS 安裝的功能 (包括語言) 會無法安裝:

Moreover, removing the Windows Component Store (WinSxS), which is responsible for a fair degree of Tiny11’s compactness, means that installing new features or languages isn’t possible.

但我記得拔掉 WinSxS 應該會影響蠻多東西的?這樣的系統應該是拿來跑跑 CI 或是固定用途還行,一般性的用途不知道會卡多少東西...

另外除了使用的磁碟空間變小以外,記憶體的使用量也大幅下降,畢竟也拔掉了一堆肥大的軟體:

In testing, NTDev said that Tiny11 could “run great” on a system with just 2GB of RAM.

目前 AWS 台北區只能開 *.2xlarge 的機器

前面在「AWS 的台北區 (Local Zone) 開了」這邊有提到機器開不起來,剛剛查價錢的時候才發現只能開 {c5,g4dn,m5,r5}.2xlarge

改成 c5.2xlarge 然後就開起來了:

翻了目前所有的 local zone,看起來大多都是類似的情況,選擇性會很少... 目前只有邁阿密與洛杉磯的選擇比較多,這是邁阿密:

這是洛杉磯:

這樣目前要拿來當 VPS 取代品還不太好用,就真的是 local zone 的定位。

XFCE 配上 Chromium 系列瀏覽器 (Chrome/Brave/...),視窗最大化時的問題

今天發現 Brave 在視窗最大化時會超出預期的邊界,而非放大到螢幕的邊緣,找了一下發現有人已經在 Brave 的 GitHub 上開了「Incorrect scale if browser is full screen #18964」這張票,後來看到有人說在 Chromium 的 bug system 上已經有人提出來了:「Issue 1257119: Goes under the taskbar when maximized」、「Issue 1260821: maximise gets screen dimension wron」與「Issue 1261797: [User Feedback - Stable] Reports that when Chrome is maximized after being minimized, it launches to beyond the window frame on Linux」。

這次遇到的 bug 看起來是只有用 XFCE 的使用者才會中獎,目前先摸索出一套 workaround 是透過 wmctrl 操作修改瀏覽器的位置與視窗大小。

方法是先用 wmctrl -l -G 列出所有視窗的資訊,包括 geometry 的資料,接著再用 wmctrl -i -r 0x12345678 -e 0,3760,15,1232,1935 這樣的指令去指定瀏覽器的位置與視窗大小。

不知道要撐多久就是了...

4px 寬的字型

也是在 Hacker News Daily 上看到的:「a pretty sweet 4px wide pixel font.」,看 commit log 似乎很久了,字本身長這樣:

作者有提到可以用在解析度不夠的螢幕上,馬上想到的是「Waveshare 3.2 inch Raspberry Pi LCD 320X240 Resistive Touch Screen TFT Display SPI LCD for Raspberry Pi 3 Model B/3B+/2 B/B/A Raspbian IMG Provided」這種東西:

另外用在小顆 LCD 單色顯示似乎也是個方法,不過看了一下是 5px:

出自「Real Time Clock On 20x4 I2C LCD Display with Arduino - Electronics-Lab.com」。

先記起來...

AWS Lambda 的消息:計費方式 1ms、上限變高、自訂 Image

這次 AWS re:InventAWS Lambda 也更新了不少東西:

首先是計價方式的改變,從本來 100ms 降到 1ms,對於這點 Cliff 有提出來了,cold start 會是成本中很重的一環 (在 https://www.facebook.com/clifflu666/posts/10214677842380050 這邊):

不過從本來的 100ms 變成現在的 1ms 只會變便宜,如果本來 100ms 的價錢就可以接受的話,現在看起來沒有理由變差 (humm,心情例外)。

會改變的是,以前可能不會想要對 cold start 最佳化 (因為做了還是收 100ms 的錢),現在就可以考慮進去讓成本再降了。

第二個是 lambda 的上限會變成 10GB RAM 與 6vCPU,剛好前幾天翻資料的時候,有翻到改版前的限制:「lambda_cpu_cores.md」,之前的上限是約 3GB 的記憶體與 2vCPU,現在拉起來讓你可以跑更大的東西...

第三個是讓你可以自訂 container image,而不需要用 AWS 提供的標準 image 跑,這點對於降低 cold start 成本也蠻有幫助的,另外一方面,總算是可以對環境客製化了...

裡面看起來最重要的應該還是第一個,計價方式讓整個成本評估大幅改變...