## OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

OpenSSL 官方給了三個 workaround 可以做，另外我還有想到一個惡搞方式，是可以用其他家免費的憑證... 不過也是得測看看在 OpenSSL 1.0.2 下會不會動。

## 在 AWS 上面的 OpenVPN Server 效能

• 前 15 秒可以直接到 5Gbps，就是 AWS 網頁上宣稱的最高速度，接下來降到 800Mbps 左右。
• 到 180 秒左右後降到 300Mbps。
• 到 210 秒左右後回到 800Mbps。
• 到 300 秒左右後降到 500Mbps。
• 到 300 秒左右後降到 300Mbps。
• 到 1260 秒左右後降到 30Mbps，後面就一直維持這個速度了。

## 抓 PDF 裡文字的問題

Hacker News Daily 上看到的，在講從 PDF 裡面拉文字出來遇到的各種問題：「What's so hard about PDF text extraction?」。

FilingDB 是一家處理歐洲公司資料的公司，可能是開公司時送件的時候要求用 PDF，或是政府單位輸出的時候用 PDF，所以他們必須從這些 PDF 裡面拉出文字分析，然後就能夠讓程式使用：

The main problem is that PDF was never really designed as a data input format, but rather, it was designed as an output format giving fine grained control over the resulting document.

At its core, the PDF format consists of a stream of instructions describing how to draw on a page. In particular, text data isn’t stored as paragraphs - or even words - but as characters which are painted at certain locations on the page.

## AMD Ryzen Threadripper 3990X 在 Windows 上的效能

John Carmack 注意到在 AMD Ryzen Threadripper 3990X 上因為 Windows 的 group limit 限制而造成效能問題：

Intel 的 14nm 牙膏繼續擠...

## 用 Amazon SES 發 Trac 通知信的問題

Trac 在發 ticket 的通知信時，會定義自己的 `Message-ID`，另外後續變更的通知信件會增加 `References` 欄位，讓 mail client 可以配對起來 (變成一個 thread)。

Amazon SES 會把原來的 `Message-ID` 改掉，使用自己的 `Message-ID` 欄位，可是 `References` 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 `Message-ID`) 與後續的信件 (`References` 所指到的信件不存在) 配對起來，只剩下後續的信件因為有相同的 `References`，所以 mail client 可以正確的配對起來。

## Raspberry Pi 4 的 Type C 無法使用 Macbook Charger 供電的問題

Raspberry Pi 4 出來後有些災情 (畢竟又加了不少東西近去)，在 Hacker News 上看到的 Type C 介面的充電問題：「Raspberry Pi 4 not working with some chargers (scorpia.co.uk)」，引用的原文可以在「Pi4 not working with some chargers (or why you need two cc resistors)」這邊看到，裡面提到了新的 Type C 供電介面在接某些充電器時不會供電 (包括了 Macbook 的充電器)：

The new pi has been released and it has a USB Type-C connector for power however people are finding some chargers are not working with it (notably macbook chargers). Some have speculated that this is due to a manufacturer limitation on the power supplies however it is actually due to the incorrect detection circuitry on the Pi end of the USB connection.

Now onto some solutions. Assuming the issue you are having is caused by the problem discussed above, using a non e-marked cable (most USB-C phone charger cables are likely this type) rather than an e-marked cable (many laptop charger/thunderbolt cables and any 5A capable cable will be in this category) will allow for the pi to be powered. In addition using older chargers with A-C cables or micro B to C adaptors will also work if they provide enough power as these don’t require CC detection to provide power. Ultimately though the best solution in the long run will be for there to be a board revision for the pi 4 which adds the 2nd CC resistor and fixes the problem.

## 從二月開始不回應 EDNS 的 DNS server 將會無法查詢

The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.

This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.