幹壞事是進步最大的原動力
在「WireGuard for macOS」這邊看到 WireGuard 進到 Apple 家的 Mac App Store 了。
除了是透過 app store 下載外，另外的重點在於整合了 NetworkExtension API：
This is built from the same code base as our existing iOS app and makes use of Apple's Network Extension API to provide native integration into the operating system's networking stack.
這樣可以確保相容性，而且可以用內建的 VPN 機制管理。另外也給了一些 screenshot 可以看，可以看出來就是走 Mac 上的管理方式：
在「openrsync imported into the tree」這邊看到 openrsync 專案進入到 OpenBSD 的 source tree 內。
rsync 是使用 GPLv3 授權，這個授權剛出來的時候，幾個比較大的 BSD 的團隊都有找律師研究過，最後都是做出不要把 GPLv3 的軟體放進 source tree 的建議，但 rsync 算是很好用的工具 (尤其是在效率上)。
看起來 openrsync 這個專案主要的目的就是重新實做出 ISC license 版本的 rsync：
This is an implementation of rsync with a BSD (ISC) license. It's compatible with a modern rsync (3.1.3 is used for testing, but any supporting protocol 27 will do), but accepts only a subset of rsync's command-line arguments.
然後目前只有設計在 OpenBSD 上跑，其他平台可能需要花些時間 porting 修正相容性：
At this time, openrsync runs only on OpenBSD. If you want to port to your system (e.g. Linux, FreeBSD), read the Portability section first.
在 GitHub 上的 Git repository 只是個 mirror，真正在管理程式碼的部份還是使用 CVS：
This repository is a read-only mirror of a private CVS repository. I use it for issues and pull requests. Please do not make feature requests: I will simply close out the issue.
AWS 針對各個 family type 都推出 Bare Metal 版本：「Now Available – Five New Amazon EC2 Bare Metal Instances: M5, M5d, R5, R5d, and z1d」。
AWS 第一次推出 Bare Metal 版本是在 2017 年年末推出的 i3.metal：「Amazon EC2 推出第一款 Bare Metal 的 Instance」，這樣算一算也一年多了，這次算是補產品線...
要注意的是，這次推出依照區域有不同的機種，像是 Ohio 沒有 z1d.metal 但有其他四種，N. California 則是沒有 m5d.metal 但有其他四種... 要先看一下表格才能確認每一區的情況 @_@
Amazon EFS 一直找不太到好用的使用情境，因為 NFS 的關係所以大量 I/O 時的 latency issue 使得速度快不起來，而拿來堆 log 的成本又超級高...
最新推出的 storage class 則是透過提供低儲存成本的版本，解決了堆 log 這種使用情境：「New – Infrequent Access Storage Class for Amazon Elastic File System (EFS)」。
不過 EFS 不像 S3 可以直接選擇 storage class，是需要讓系統管理的：
開啟後 30 天沒有被碰過的檔案就會切過去：
Eligible Files – Files that are 128 KiB or larger and that have not been accessed or modified for at least 30 days can be transitioned to the new storage class. Modifications to a file’s metadata that do not change the file will not delay a transition.
而 latency 也會增加：
Files that have not been read or written for 30 days will be transitioned to the Infrequent Access storage class with no further action on your part. Files in the Standard Access class can be accessed with latency measured in single-digit milliseconds; files in the Infrequent Access class have latency in the double-digits.
以 us-east-1 為例子來說，Standard 是 USD$0.3/GB-month，而 IA 只要 USD$0.045/GB-month，但抓取時會有 USD$0.01/GB 的傳輸費用，可以看出價錢低不少。
不過文章裡沒提到什麼時候會把資料從 IA 跳回 Standard，可能得找機會問問看...
在「How to Migrate from Microsoft SQL Server to PostgreSQL」這邊看到作者的客戶需要把 Microsoft SQL Server 轉移到 PostgreSQL (但沒有提到原因)。
裡面主要是兩個階段的轉換，第一個階段是 schema 的轉換，作者提到了 dalibo/sqlserver2pgsql 這個用 Perl 寫的工具：
Migration tool to convert a Microsoft SQL Server Database into a PostgreSQL database, as automatically as possible http://dalibo.github.io/sqlserver2pgsql
第二個階段是資料的轉換，是選擇用 Pentaho Data Integration 的 Community Edition：
Pentaho offers various stable data-centric products. Pentaho Data Integration (PDI) is an ETL tool which provides great support for migrating data between different databases without manual intervention. The community edition of PDI is good enough to perform our task here. It needs to establish a connection to both the source and destination databases. Then it will do the rest of work on migrating data from SQL server to Postgres database by executing a PDI job.
所以用兩個工具串起來... 另外在文章裡面沒提到 stored procedure 之類的問題，應該是他們的客戶沒用到或是很少用到？
FOSDEM 2019 上的演講，討論 PostgreSQL 在確保 ACID 特性中的 Durability 時遇到 fsync() 的行為跟預想的不一樣 (主要是當 fsync() 失敗的行為)：「PostgreSQL vs. fsync」。
在「PostgreSQL vs. fsync. How is it possible that PostgreSQL used fsync incorrectly for 20 years, and what we'll do about it.」這邊的 Q&A 形式的訪談有快速描述了短期的計畫與長期的想法：
The short-term solution is ensuring that we detect fsync errors reliably at least on sufficiently recent kernels (since 4.13). On older kernels we can’t do much better, unfortunately.
The long-term solution is still being discussed in the community, but it’s hard to say how we could keep relying on buffered I/O in the future. So we may end up with direct I/O, but that’s a pretty significant change and is likely going to be a multi-year project.
在 MySQL 這邊則是以 O_DIRECT 為主的世界，受到的影響就小很多了...
先前有提到 Linode 出了 Dedicated 主機：「Linode 推出 Dedicated CPU Instances」，現在找機會測試看看，拿了 Linode 的 Dedicated (4GB) 與 AWS 的 c5.large 比較，同樣都是 2 vCPU 與 4GB RAM。
這邊用了 n-st/nench 與 OpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試，我把結果都貼到這邊：「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。
可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD，而 AWS 用的是 Intel，所以就會有蠻多不同的數字表現...
如果仔細看 OpenSSL 的測試數據，可以看到不同演算法的差異還蠻大的，馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的：
如果考慮到價位大約只有 AWS 的一半，應該是還不錯...
RISC-V 是目前最有名的 open source 指令集，但似乎不太好找對應的硬體... 在「Building a RISC-V PC」這篇則是介紹了怎麼弄一台 RISC-V 的 PC：
採用的硬體是 HiFive Unleashed (USD$999)，硬體架構包括了：
沒有 USB 與 HDMI，作者是透過 HiFive Unleashed Expansion Board (USD$1999) 接出來的，不過這張還包括了 FPGA，這好像有點超過，兩個套件再加上 M.2 或是 SATA 的 disk 應該是超過台幣十萬...
不過畢竟算是早期的產品，之後有規模後應該會開始有中低價位的產品出現...
看到「Mercury Goes Open Source!」這篇，Postlight 的團隊開源了 Mercury Web Parser，程式碼在 GitHub 上的 postlight/mercury-parser 可以取得。
這個版本是用 Node.js 寫的，可以從範例看出用法以及結果：
import Mercury from '@postlight/mercury-parser'; Mercury.parse(url).then(result => console.log(result););
{
"title": "Thunder (mascot)",
"content": "<div><div><p>This is the content of the page!</div></div>",
"author": "Wikipedia Contributors",
"date_published": "2016-09-16T20:56:00.000Z",
"lead_image_url": null,
"dek": null,
"next_page_url": null,
"url": "https://en.wikipedia.org/wiki/Thunder_(mascot)",
"domain": "en.wikipedia.org",
"excerpt": "Thunder Thunder is the stage name for the horse who is the official live animal mascot for the Denver Broncos",
"word_count": 4677,
"direction": "ltr",
"total_pages": 1,
"rendered_pages": 1
}先前其他的軟體與服務可以參考「Evaluating Text Extraction Algorithms」這篇的整理與比較，不過這篇連原網站都不見了... 只能從 Internet Archive 上翻出來。
這個主題有不少團隊都做過 (給一個 html 網頁，抓出實際的內容塊落)，但也死了不少團隊... 比較有印象的是 Readability，在 2016 年收掉了：「The Readability bookmarking service will shut down on September 30, 2016.」。
要撈資料可以拿來用...
在「What Happened to the 100,000-Hour LED Bulbs?」這邊看到在討論 LED 燈泡的壽命。比較感興趣的是到底業界怎麼計算 LED 燈泡的壽命。
前面提到很多因使用時間的增加而產生衰退與色偏，然後講到「壽命」的定義是，超過一半的燈泡低於 70% 的原始亮度所需要的時間：
Research says that most users won’t notice a gradual 30% drop in light levels; accordingly the industry has defined L70, the time at which the output has dropped to 70% of its initial level, as an endpoint for measuring LED bulb lifetime. Based on how it’s estimated, this measure is typically stated as B50-L70, the point at which 50% of an initial sample of bulbs will retain 70% of their rated output.
另外一個有趣的資料是，LED 燈泡故障的原因中，電源供應相關佔了最大的比率 (過半)：
算是個有趣的知識...