幹壞事是進步最大的原動力
也是在 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：
先記起來...
在 Hacker News Daily 上看到「25 Gigabit Linux internet router PC build」這個，Hacker News 上的討論在「25 Gigabit Linux internet router PC build (stapelberg.ch)」這邊，文章裡面在講怎麼用 PC 建 25Gbps 的 router，不過大家基本上都是在討論其他事情...
先從服務本身來看，是瑞士的 ISP Init7 提供的服務：「Fiber7-X2」，月繳的話大約是 NTD$2100/month，打開 nerd mode 可以看到說明，是直接給你非 CGNAT 的動態 IPv4 位置以及固定的 IPv6 /48 位置：
The IPv4 address is part of our AS13030 backbone - not a Carrier-Grade-NAT address like with other providers. A fixed IPv4 or a /29 subnet are available for an additional charge. A static IPv6 /48 network is included free of charge. The addressing is done via DHCPv6-PD prefix delegation. Optimal ping times, transparent routing and an open peering policy make Fiber7 the kind of internet offer there always should have been.
另外翻了 FAQ，找到固定 IPv4 位置的價錢：「Can I get static IPv4 addresses?」，一個 IPv4 位置大約是 NTD$7200/year。
另外在「Recommended hardware」這邊看起來應該是沒提供 router，使用者要自己接準備 router 設備直接接，其中 25Gbps 的 Fiber7-X2 規格是：
Fiber7-X2: 25G SFP28 BIDI LR, 10 km, TX1270/RX1330 nm, LC-Simplex, Singlemode
在 ISP 推薦的硬體設備裡，支援 Fiber7-X2 的只有 MikroTik CCR2004-1G-12S +2XS，但只能跑到 15Gbps：
throughput: up to 15 Gbit/sec
難怪作者會想要自己搞 router...
順便查了一下 PCI Express 的速度資料，PCIe 3.0 下 2x 可以到 1.97GB/sec，勉勉強強擦到 25Gbps 的邊邊？文章作者這邊用了 PCIe 3.0 8x 的 Intel XXV710AM2 來解決。
整體裝起來看起來沒什麼問題，只能說是奢侈的煩惱 XD
在 Hacker News 上看到的 dark pattern：「NDA Expired - let's spill the beans on a weird startup」，對應的討論可以在「NDA expired, let’s spill the beans on a weird startup (shkspr.mobi)」這邊翻到。
整個行銷手法大概是這樣，首先是客戶會想要推廣某個產品 (文章內的 AWS 想要推廣 InfiniDash 這個產品)，所以找上這個行銷公司。而行銷公司會找一群人去各公司 interview，然後在 interview 過程中問到各種問題的時候都回答用 InfiniDash 這個產品解決：
"Let's say in the interview you're asked for a time when you handled a difficult situation. We want you to talk about how using InfiniDash made life easier for your team."
這個行銷公司會跟某些獵頭合作，把人塞進去 (而這些獵頭也會拿到錢)：
"Oh, we work with loads of recruitment consultants. They get paid for every decent candidate who gets interviewed, so they give us a cut of their commission. And we get paid by our tech clients. It's win-win!"
後來作者沒有加入這家公司，而這家公司後來也消失了：
I did not take the job. I had serious concerns about the ethics and legality of their business model. I also didn't think that it would work. Evidently, neither did their investors. Fronk bumbled along for a few months - and I'd occasionally meet them at conferences - but then they seemed to disappear.
但作者最後提到了他之後在 interview 時會聽到面試者講一些特定的產品，讓他懷疑這家公司是不是還存在 XDDD
Every once in a while, I'll be interviewing a candidate who starts waxing lyrical about how rewriting everything in today's flavour of JavaScript really helped their last company. Or how their bosses were impressed with what this cool new bit of tech can do. Or why they could never work anywhere which didn't use this specific code editor.
在 Hacker News Daily 上看到「Kaspersky Password Manager: All your passwords are belong to us」這篇，講 Kaspersky Password Manager (KPM) 嚴重的安全漏洞，另外在 Hacker News 上的討論「Kaspersky Password Manager: All your passwords are belong to us (ledger.com)」也有提到一些有趣的東西。
標題的 All your passwords are belong to us 是出自「All your base are belong to us」這個梗的變形。
這包安全問題主要的原因是因為 KPM 沒有使用 CSPRNG，而且也沒有正確 seed，所以極為容易被猜出密碼本身。
KPM 的 Web 版使用了 Math.random()，在各家瀏覽器主要是用 xorshift128+ 實做 Math.random()，作者沒有針對這塊再花時間研究，但很明顯的 Math.random() 不是個 CSPRNG：
The underlying PRNG used by Chrome, Firefox and Safari for Math.random() is xorshift128+. It is very fast, but not suitable to generate cryptographic material. The security consequences in KPM has not been studied, but we advised Kaspersky to replace it with window.crypto.getRandomValues(), as recommended by the Mozilla documentation page previously mentioned.
Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.
而桌機版則是用了 MT19937，理論上取得 624 bytes 的輸出後就可以重建整個 PRNG 的內部狀態 (於是就可以預測後續的 output)，但這代表你要知道其他網站的密碼，這點其實有點困難。
但作者發現 KPM 在產生 MT19937 的 seed 只跟時間有關，超級容易被預測：
So the seed used to generate every password is the current system time, in seconds. It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.
於是可以直接暴力解出所有的可能性：
The consequences are obviously bad: every password could be bruteforced. For example, there are 315619200 seconds between 2010 and 2021, so KPM could generate at most 315619200 passwords for a given charset. Bruteforcing them takes a few minutes.
Hacker News 上有不少陰謀論的討論，像是：
Getting some DUAL_EC prng vibes.
Insert Kaspersky owned by Russia intelligence conspiracy here...
另外 Kaspersky 跟俄羅斯軍方的關係也是很知名，這些東西大概要到十來年後才會知道...
在 Hacker News 首頁看到「Show HN: RSS feeds for arbitrary websites using CSS selectors (vincenttunru.com)」這個，程式在 GitLab.com 上的「Feed me up, Scotty!」這邊，另外這個專案名稱是在玩 Star Trek 的梗：「Beam me up, Scotty」，然後這邊講的 RSS feed 已經算是通稱了，實際上大家都是輸出 Atom。
他用的設定檔格式是 TOML，文章給的範例：
[funfacts] title = "Wikipedia — did you know?" url = "https://en.wikipedia.org/wiki/Main_Page" entrySelector = "#mp-dyk > ul li" titleSelector = "b" linkSelector = "b a" [wikivoyage] title = "Wikivoyage recommendations" url = "https://en.wikivoyage.org/wiki/Main_Page" entrySelector = ".jcarousel-wrapper .jcarousel-item" titleSelector = "h2" linkSelector = "h2 a"
從 feed-me-up-scotty/src/index.ts 這邊看起來是 TypeScript 專案，然後用 browser 帶起 Firefox 來，可以預期會吃不少資源...
另外 Hacker News 的討論裡有另外提到「Feed Creator」，看起來也是個不錯的專案，有免費版與付費版...
在 mailing list 上看到「Test Git repository for INN」這個消息，看起來 InterNetNews 也在嘗試換到 Git 上了，目前是選擇用 GitHub，在「InterNetNews/inn」這邊。
整個從 CVS 換到 Subversion 再到現在開始進入 Git 的環境了。
沒有全部自己搞的理由也有提到，主要就是免費與方便，然後社群也已經知道 GitHub 是什麼了：
GitHub was chosen because it's (a) free (as in price), (b) widely understood and used already, and (c) easy for me to set up. I know some folks have reservations about GitHub because it's not free software, and I understand, but I don't think we're committing heavily to their platform (everyone who has a clone of the Git repository has all the important data and can move it elsewhere), and other things like GitLab are only open core anyway. Hosting everything on 100% free software (depending on the choice of free software) loses us some useful features (I plan to set up GitHub Actions for CI) and requires more resources that I don't really have to spend on it. That said, everyone is certainly welcome to mirror the Git repository elsewhere if they want.
之後會跑 CI，算是這些年軟體工程必備的工具了...
看到「Encoding data for POST requests」這篇大家才回頭注意到 GitHub Copilot 首頁的範例本身就有安全漏洞：
async function isPositive(text: string): Promise<boolean> {
const response = await fetch(`http://text-processing.com/api/sentiment/`, {
method: "POST",
body: `text=${text}`,
headers: {
"Content-Type": "application/x-www-form-urlencoded",
},
});
const json = await response.json();
return json.label === "pos";
}
其中 text=${text} 是一個 injection 類的漏洞，首頁的範例應該是被挑過的，但仍然出現了這個嚴重的問題，從這邊可以看出 GitHub 與 OpenAI 在這條線上的問題...
Simon Willison 提出來「PAGNIs: Probably Are Gonna Need Its」，整理一下裡面提到的功能。
第一個是 kill switch，在 API 設計上一開始納入強制升級的傳回值，文章裡面有提到一些情境。
第二與第三剛好就是 Test + CI + CD，常常是 best practice，除了文章裡面提到的東西，在其他人的文章裡面應該也都有類似的討論。
第四是 API 的分頁，這個部份只講了要分頁，沒講到分頁時資料庫的效率問題，這部份可以參考「API pagination best practices」這邊的討論，key-based 的 pagination 效能會比較好，也可以避免對資料庫的 DoS 攻擊。
第五是 API 的 log，作者的建議是一開始什麼都存起來，等量大的時候再拔掉，會對於初期開發與除錯很有幫助。我是會掛 Sentry 這類的東西，有錯誤的時候會記錄起來。
第六看不懂他想要幹什麼，先跳過去。第七是在講要盡早實做這些 practice，等專案都推出去後再回過來實做都很花時間。
有些可以練手一下...