以前好像沒遇過，換了 M1 以後才注意到 desktop 位置位自己被改變，覺得很阿雜... 找了資料才發現是個 "feature"：「How to prevent Mac from changing the order of Desktops/Spaces」。
關掉就好了，網路上的資料最早出現在 2018 年左右，大概是那個時候被加進去的？
Mac 會自己改變 Desktop 位置的問題
Tag: bug
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’slibgfortranis missing alibquadmathbuild dependency. It is natural not to encounter it in real world aslibquadmathis usually built along with other small runtimes way beforeg++orgfortranis ready.
他的基本想法是把 target 的順序打亂掉，也就是在有指定 --shuffle 時，不一定會照 a -> b -> c 的順序往下遞迴，而可能會是 c -> b -> a 或是其他的順序：
all: a b c
這樣對於抓那些在 -j 平行編譯時會出包的套件也很有幫助，不需要在 -j 開很大的情況下才能重製問題，而是平常就有機會在 CI 環境下被抓出來。
CSS 的 feature detection：@support
在「Conditional CSS」這篇裡面在講很多 CSS 條件過濾的方式，裡面看到有 @support 這個規格，可以透過 feature detection 的方式來過濾：「CSS at-rule: @supports: selector()」。
文章作者給的範例是這樣：
@supports selector(:has(p)) {
.card-thumb {
aspect-ratio: 1;
}
}
在瀏覽器支援 :has(p) 的情況下才指定裡面的 CSS。
翻了一下 @support 在各家瀏覽器上實做的情況：在 Firefox 上是 69 開始支援，推出的日期是 2019/09/03。在 Chrome 上是 83 開始支援，推出的日期是 2020/05/19。在 Safari 上是 14.1 開始支援 (對應到 iOS 版本是 14.5)，推出的日期是 2021/04/26。
從日期可以看出來算是比較新的功能，但主要幾個大的瀏覽器都支援了。
這個讓我想起來早期利用各家瀏覽器的 bug 產生出的各種 hack：「Browser Specific Hacks」。
解決 Ubuntu 重開機後麥克風聲音太小的問題
Ubuntu 桌機重開機後會遇到外接 USB 麥克風 AM310 的聲音會變得太小的問題，常常是開會的時候被同事提醒才去調。
查了一下是不是有 bug，看起來跟「Mic input volume always resets (to middle/low value) on resume or restart」這個 bug 有關，但這個回報是 16.04，到現在 22.04 都出了，好像沒有新進度...
接著就是找看看有沒有 workaround 可以用，其中一種想法是找出用 command line 設定音量的方式，這樣就可以在開機的時候自動執行。
接著就找到「How can i increase microphone volume beyond 100%」這個問答，首先用這個指定列出所有的 source：
pactl list sources
裡面可以看到 AM310 的資料，接著就可以透過 name 的部份指定音量了：
pactl set-source-volume alsa_input.usb-AVerMedia_AVerMedia_AM310_USB_Microphone-00.multichannel-input 70%
放到 startup script 在 login 的時候跑就 OK 了。
用 dig 查瑞士的 top domain 剛好會遇到的 "feature"
在 Hacker News 上看到「DNS Esoterica - Why you can't dig Switzerland」這篇，裡面提到 dig 的 "feature"。
拿來查 tw 的 NS 會這樣下：
$ dig tw ns
結果會是列出所有的 NS server：
;; ANSWER SECTION: tw. 3600 IN NS h.dns.tw. tw. 3600 IN NS a.dns.tw. tw. 3600 IN NS g.dns.tw. tw. 3600 IN NS d.dns.tw. tw. 3600 IN NS anytld.apnic.net. tw. 3600 IN NS f.dns.tw. tw. 3600 IN NS b.dns.tw. tw. 3600 IN NS e.dns.tw. tw. 3600 IN NS c.dns.tw. tw. 3600 IN NS ns.twnic.net.
照著作者說的，uk 的 dig uk ns 可以得到類似的結果：
;; ANSWER SECTION: uk. 86400 IN NS dns1.nic.uk. uk. 86400 IN NS dns4.nic.uk. uk. 86400 IN NS nsa.nic.uk. uk. 86400 IN NS nsb.nic.uk. uk. 86400 IN NS nsc.nic.uk. uk. 86400 IN NS nsd.nic.uk. uk. 86400 IN NS dns3.nic.uk. uk. 86400 IN NS dns2.nic.uk.
但如果你下 dig ch ns 就會出現錯誤，像是這樣：
; <<>> DiG 9.16.1-Ubuntu <<>> ch ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5019 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. CH NS ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 15 06:54:24 CST 2022 ;; MSG SIZE rcvd: 28
原因是因為 CH 這個關鍵字是 Chaosnet 的縮寫，而被特殊解讀：
Set the query class. The default class is IN; other classes are HS for Hesiod records or CH for Chaosnet records.
要避開這個解讀需要加上一個 dot (.)，採用 FQDN 的方式列出：
dig ch. ns
就會得到正確的結果：
;; ANSWER SECTION: ch. 86400 IN NS a.nic.ch. ch. 86400 IN NS b.nic.ch. ch. 86400 IN NS f.nic.ch. ch. 86400 IN NS d.nic.ch. ch. 86400 IN NS e.nic.ch.
另外的方式是 dig -c IN -t NS ch，透過參數的方式讓 dig 不會誤會。
Hacker News 前幾天炸很久的 root cause
前幾天 Hacker News 炸了很久，如果是從 Twitter 上的資料來看，是從 2022/07/08 14:08 UTC 這篇：
HN is down again with what appears to be a second disk failure. This is on the fallback server, which we switched to last night when the primary server failed. Will update when we know more. Sorry all!
— Hacker News Status (@HNStatus) July 8, 2022
中間還原失敗 (2022/07/08 17:35 UTC)：
Working on restoring from backups the slow way, since failover server also failed. No ETA yet, but we're getting there.
— Hacker News Status (@HNStatus) July 8, 2022
到最後恢復 (2022/07/08 20:48 UTC)：
HN is running again, on a new server created from backups. Will be monitoring closely. Sorry everyone for the inconvenience!
— Hacker News Status (@HNStatus) July 8, 2022
Twitter 這邊的資料看起來差不多是六個小時多，以一個應該是只有 database 需要還原的站台來說的確是蠻久的，所以後續在「HN is up again」這邊就有在討論原因，裡面 HN 的老大 dang 也有提到 downtime 是七個小時多：
8 hours of downtime, but not data loss, since there was no data to lose during the downtime.
Last post before we went down (2022-07-08 12:46:04 UTC): https://news.ycombinator.com/item?id=32026565
First post once we were back up (2022-07-08 20:30:55 UTC): https://news.ycombinator.com/item?id=32026571 (hey, that's this thread! how'd you do that, tpmx?)
So, 7h 45m of downtime. What we don't know is how many posts (or votes, etc.) happened after our last backup, and were therefore lost. The latest vote we have was at 2022-07-08 12:46:05 UTC, which is about the same as the last post.
There can't be many lost posts or votes, though, because I checked HN Search (https://hn.algolia.com/) just before we brought HN back up, and their most recent comment and story were behind ours. That means our last backup on the ill-fated server was taken after the last API update (HN Search relies on our API), and the API gets updated every 30 seconds.
I'm not saying that's a rock-solid argument, but it suggests that 30 seconds is an upper bound on how much data we lost.
另外大家就在找 dang 的回應是什麼 (畢竟是第一手資料)，用 Ctrl-F 找一下就看到有趣的猜測，從 32028511 這個節點可以看到這串有趣的討論，首先是 mikeiem：
You are never going to guess how long the HN SSDs were in the servers... never ever... OK... I'll tell you: 4.5years. I am not even kidding.
然後是 kabdib 的回應：
Let me narrow my guess: They hit 4 years, 206 days and 16 hours . . . or 40,000 hours.
And that they were sold by HP or Dell, and manufactured by SanDisk.
Do I win a prize?
(None of us win prizes on this one).
接著就是 dang 說他覺得這個猜測很有可能：
Wow. It's possible that you have nailed this.
Edit: here's why I like this theory. I don't believe that the two disks had similar levels of wear, because the primary server would get more writes than the standby, and we switched between the two so rarely. The idea that they would have failed within hours of each other because of wear doesn't seem plausible.
But the two servers were set up at the same time, and it's possible that the two SSDs had been manufactured around the same time (same make and model). The idea that they hit the 40,000 hour mark within a few hours of each other seems entirely plausible.
Mike of M5 (mikiem in this thread) told us today that it "smelled like a timing issue" to him, and that is squarely in this territory.
後續他也從自家的 /newest 裡面撈了相關的資料出來，依照他撈出來的關鍵字，看起來是用 HPE 出的 SSD：
It's also an example of the dharma of /newest – the rising and falling away of stories that get no attention:
HPE releases urgent fix to stop enterprise SSDs conking out at 40K hours - https://news.ycombinator.com/item?id=22706968 - March 2020 (0 comments)
HPE SSD flaw will brick hardware after 40k hours - https://news.ycombinator.com/item?id=22697758 - March 2020 (0 comments)
Some HP Enterprise SSD will brick after 40000 hours without update - https://news.ycombinator.com/item?id=22697001 - March 2020 (1 comment)
HPE Warns of New Firmware Flaw That Bricks SSDs After 40k Hours of Use - https://news.ycombinator.com/item?id=22692611 - March 2020 (0 comments)
HPE Warns of New Bug That Kills SSD Drives After 40k Hours - https://news.ycombinator.com/item?id=22680420 - March 2020 (0 comments)
(there's also https://news.ycombinator.com/item?id=32035934, but that was submitted today)
這次 downtime 看起來很像是中了 SSD firmware bug，目前看起來先搬到 EC2 上面了：
$ host news.ycombinator.com news.ycombinator.com has address 50.112.136.166 $ host 50.112.136.166 166.136.112.50.in-addr.arpa domain name pointer ec2-50-112-136-166.us-west-2.compute.amazonaws.com.
看討論串應該是暫時性的？
這次 OpenSSL 的兩個 CVE
難得在 Hacker News 首頁上看到 OpenSSL 的 CVE：「OpenSSL Security Advisory [5 July 2022]」，相關的討論在「OpenSSL Security Advisory (openssl.org)」。
第一個 CVE 是 RCE 等級，但觸發條件有點多：
首先是 RSA 2048bits，這個條件應該算容易發生的。
第二個是，因為這個安全問題是因為 OpenSSL 3.0.4 才引入的程式碼，而 OpenSSL 3.0.4 是 2022/06/21 發表的，未必有很多人有升級。
第三個是，因為這次出包的段落是用到了 AVX-512 指令集，一定要 Intel 或是 Centaur 的 CPU，後面這家公司前身就是威盛 (VIA) 的一員，去年賣給了 Intel (然後發現連官網用的 domain 都沒續約...)。
而 AMD 雖然在 Zen 4 架構上支援 AVX-512，但還沒推出產品，所以直接閃避 XD
另外第三個還有額外的限制，因為這次用到的是 IFMA 指令集，所以也不是所有有支援 AVX-512 的 CPU 都會中獎：
只看 Intel 的部份，第一個支援 IFMA 的是 2018 年推出的 Cannon Lake，這個架構只有一顆行動版的 Intel® Core™ i3-8121U Processor。
真正大量支援 IFMA 的是 2019 後的 Intel CPU 了，但到了去年推出的 Alder Lake 因為 E-core 不支援 AVX-512 的關係 (但 P-core 支援)，預設又關掉了。
所以如果問這個 bug 嚴不嚴重，當然是很嚴重，但影響範圍就有點微妙了。
接下來講第二個 CVE，是 AES OCB 的實做問題，比較有趣的地方是 Hacker News 上的討論引出了 Mosh 的作者跳出來說明，他居然提到他們在二月的時候試著換到 OpenSSL 的 AES OCB 時有測出這個 bug，被 test case 擋下來了：
Mosh uses AES-OCB (and has since 2011), and we found this bug when we tried to switch over to the OpenSSL implementation (away from our own ocb.cc taken from the original authors) and Launchpad ran it through our CI testsuite as part of the Mosh dev PPA build for i686 Ubuntu. (It wasn't caught by GitHub Actions because it only happens on 32-bit x86.) https://github.com/mobile-shell/mosh/issues/1174 for more.
So I would say (a) OCB is widely used, at least by the ~million Mosh users on various platforms, and (b) this episode somewhat reinforces my (perhaps overweight already) paranoia about depending on other people's code or the blast radius of even well-meaning pull requests. (We really wanted to switch over to the OpenSSL implementation rather than shipping our own, in part because ours was depending on some OpenSSL AES primitives that OpenSSL recently deprecated for external users.)
Maybe one lesson here is that many people believe in the benefits of unit tests for their own code, but we're not as thorough or experienced in writing acceptance tests for our dependencies.
Mosh got lucky this time that we had pretty good tests that exercised the library enough to find this bug, and we run them as part of the package build, but it's not that farfetched to imagine that we might have users on a platform that we don't build a package for (and therefore don't run our testsuite on).
這有點有趣 XDDD
Laravel 將不會有 LTS 版本
查資料的時候發現，在 Laravel 9 剛發佈的時候是有掛 LTS 版本的資訊 (從「Laravel 9 (LTS) 出了」這邊的截圖可以看到)，但在發佈後沒多就就被拿掉了，在 Taylor Otwell 的 Twitter 上有提到這件事情：
Some have noticed L9 is no longer listed as "LTS" in our release notes.
Waiting to see the resolution of this: https://t.co/F5YCkJNKjt
It could determine how we approach Laravel 9 long-term support.
Regardless, Laravel 9 will receive security updates for at least 2 years.
— Taylor Otwell 🪐 (@taylorotwell) February 10, 2022
從幾個 forum 討論的態度上看起來以後不會出新的 LTS 版本了，之後的版本都是提供一年的 bug fix + security fix，再加上另外一年的 security fix，基本上有兩年的 support，算是半強迫開發者時間到了就要升級版本...
另外一個有看到的問題是，現在的 Laravel 9 支援的 PHP 版本因為底層 Symfony 要 PHP 8.0+ 關係也一起被拉上來，連 PHP 7.4 都不支援了：
這個靠「***** The main PPA for supported PHP versions with many PECL extensions *****」這類 3rd-party repository 來補是還能解，但感覺 Symfony 對這些問題的態度...
Google Docs 裡 Grammar Correction 的 bug
剛剛在 Hacker News 上看到有趣的 bug，在 Google Docs 上輸入 And. And. And. And. And. 會觸發 error：「Including “And. And. And. And. And.” in a Google doc causes it to crash (support.google.com)」，原始的 bug report 在「Including "And. And. And. And. And." in a Google doc causes it to crash.」這邊，錯誤訊息像是這樣：
Hacker News 上的討論有提到這需要開 grammar check 的功能，然後看起來只要有相同的五個字開頭都大寫就會發生，像是 Also, Therefore, And, Anyway, But, Who, Why. 這些：
Also, Therefore, And, Anyway, But, Who, Why.
Each in caps 5 times with the same word with a period and space after each word and newline at the end is what I have found so far.
Can anyone find others?
Edit: added words that work found in other comments
很有趣的 bug XDDD 然後目前在 Hacker News 首頁的第一名...
