擋廣告的 Pi-hole

Pi-hole 最近愈來愈紅的一個計畫,技術上是透過 DNS 把不想要的網域名稱擋掉,通常就是擋掉各種 tracking 與廣告系統。

因為是透過 DNS 擋,當然沒有像 uBlock Origin 直接 parse 網頁內容來的有效,但對於方便性來說則是大勝,只需要在網路設備上設一次,所有的裝置都可以用到。

剛剛看到「How a Single Raspberry Pi made my Home Network Faster」這篇,可以看到 Pi-hole 有不錯的介面可以看 (讓你自我感覺良好?XD):

文章作者跑了一個月後,也直言還是有些東西會壞掉,需要設定一些白名單讓他動:

Review after 1 month in operation
The Pi-Hole has been running for 1 month now on my home network. I have had to whitelist 1 or 2 URLs which was blocking a reset of an Alexa which had an issue, and a video conferencing system had all sorts of tracking and metrics built in which were causing some havoc until I whitelisted them. Otherwise, the Pi has been chugging along at 8% memory utilization, and the network is considerably faster when surfing the web.

對於手癢自己玩應該還可以,拿到辦公室的話應該會有不少東西掛掉... (不過文章作者好像想這樣做)

美國政府發行的字型 Public Sans

Public Sans 是一套美國政府出資而產生的無襯線字型,專案放在 GitHub 上 (uswds/public-sans)。這套自行不是全部都自己刻,而是改自於 Libre Franklin Font (以 SIL Open Font License v1.1 授權,而 Public Sans 沿用同樣授權)。

第一個目標是授權:

Be available as a free, open source webfont on any platform.

另外是使用的廣度:

Have a broad range of weights and a good italic.
Perform well in headlines, text, and UI.

Have good multilingual support.
Allow for good data design with tabular figures.

在 GitHub 頁面上有整理與 Libre Franklin 的差異,可以看到配合現在的呈現媒體而做了不少調整。

GrabFood 用定位資料修正餐廳的資訊

Grab 的「How we harnessed the wisdom of crowds to improve restaurant location accuracy」這篇是他們的 data team 整理出來,如何使用既有的資料快速的修正餐廳資訊。裡面提到的方法不需要用到 machine learning,光是一些簡單的統計算法就可以快速修正現有的架構。

這些資訊其實是透過司機用的 driver app 蒐集來的,在 driver app 上有大量的資訊傳回伺服器 (像是定時回報的 GPS 位置,以及取餐狀態),而這些司機因為地緣關係,腦袋裡的資訊比地圖會準不少:

One of the biggest advantages we have is the huge driver-partner fleet we have on the ground in cities across Southeast Asia. They know the roads and cities like the back of their hand, and they are resourceful. As a result, they are often able to find the restaurants and complete orders even if the location was registered incorrectly.

所以透過這些資訊他們就可以反過來改善地圖資料,像是透過司機按下「取餐」的按鈕的地點與待的時間,就可以估算餐聽可能的位置,然後拿這個資訊比對地圖上的資料,就很容易發現搬家但是地圖上沒更新的情況:

Fraction of the orders where the pick-up location was not “at” the restaurant: This fraction indicates the number of orders with a pick-up location not near the registered restaurant location (with near being defined both spatially and temporally as above). A higher value indicates a higher likelihood of the restaurant not being in the registered location subject to order volume

Median distance between registered and estimated locations: This factor is used to rank restaurants by a notion of “importance”. A restaurant which is just outside the fixed radius from above can be addressed after another restaurant which is a kilometer away.

另外也有不少其他的改善 (像是必須在離餐聽某個距離內才能點「取餐」,這個「距離」會因為餐聽可能在室內商場而需要的調整),整個成果就會反應在訂單的取消率大幅下降:

整體看起來是系統產生清單後讓人工後續處理 (像是打電話去店家問?),但這個方式所提供的清單準確度應該很高 (因為司機不會沒事跟自己時間過不去,跑到奇怪地方按下取餐),用這些資料跑簡單的演算法就能夠快速修正不少問題...

Google 內部的系統 (以及外部可能的 Open Source 替代方案)

Hacker News Daily 上看到的 jhuangtw-dev/xg2xg,整理了 Google 內部服務以及可能的替代方案。

主要是提供給離開 Google 的工程師,替代方案中包括了 Google 自己公佈的,已經其他的 open source 替代方案:

by ex-googlers, for ex-googlers - a lookup table of similar tech & services

A handy lookup table of similar technology and services to help ex-googlers survive the real world :) pull-requests very welcomed. Please do not list any confidential projects!

專案的發起人看起來是個台灣人...

修正 Mac 外接螢幕的 Underscan 問題

公司的 MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) 透過 HDMI 接 Dell P2419H 一直都有 Underscan 的問題:


出自「About overscan and underscan on your Mac, Apple TV, or other display

本來想透過 Underscan slide 修改 (像是下面這張圖),但發現系統內沒有 Underscan slide。


出自「About overscan and underscan on your Mac, Apple TV, or other display

找了不少文章後後來是在「Fixing Issues with Overscan/Underscan(Black Borders) on macOS」這篇的 comment 看到解法:

Ran into this same underscan problem with black borders showing up on my new Dell 24-inch Ultrasharp U2415 connected to a 2013 Macbook Air running High Sierra, and after hours of looking into the problem the fix turned out to be super simple:

Just restart in Safe Mode.

That’s it. Restart your Mac in Safe Mode (restart, hold down the Shift key after the Apple BONG sounds, then restart normally once again for good measure. I don’t know what this clears or resets but it worked for me. No more letterboxing or black borders with the native 1920×1200 resolution selected.

So maybe something to try first for anyone coming across this post.

照著重開進 Safe mode 後再開回一般模式就正常了 (what???),先記錄起來,讓我之後遇到時可以搜尋到自己的文章...

DigitalOcean 買下 Nanobox

DigitalOcean 宣佈買下 Nanobox:「Nanobox Joins the DigitalOcean Family」。

Nanobox 是一個類似 Heroku 的服務,提供平台 (Platform) 讓開發者不需要自己架設伺服器,就可以直接把寫好的程式丟上去跑。

這次 DigitalOcean 買下 Nanobox 算是跟他們產品走向一致,提供更上層的應用,降低開發者要接觸營運這塊的門檻。另外之前提供了 PostgreSQL 的服務 (類似 Amazon RDS) 也是類似的想法。

不過 DigitalOcean 的機器速度不快,如果是因為價位而不想用 Heroku 的人,應該也會猶豫... 如果預算不是太大問題的話,其實 Heroku 還蠻好用的?目前想不到有什麼關鍵的優勢...

Gmail 宣佈支援 MTA-STS

Gmail 宣佈支援 MTA-STS:「Gmail making email more secure with MTA-STS standard」。這邊提到的 MTA-STS 是透過某些設定,讓 SMTP 送信時強制使用 TLS 的機制,可以參考「SMTP 的強加密連線機制」這篇。

可以看到有 TXT,也有 .well-known 檔案:

;; ANSWER SECTION:
_mta-sts.gmail.com.     300     IN      TXT     "v=STSv1; id=20171114T070707;"

$ curl https://mta-sts.gmail.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

如果要自己設定的話可以參考 Google 提供的「About MTA-STS and TLS Reporting」這篇,不過目前中文版文件還沒有更新,請切到英文版...

Amazon CloudFront 要增加自訂網域名稱需要先過認證...

大概猜得到原因,總算是把這塊做下去了...

AWS 宣佈 CloudFront 增加自訂網域名稱需要先過認證才能啟用:「Amazon CloudFront enhances the security for adding alternate domain names to a distribution」,也就是把自己的 domain name 掛到 CloudFront 上需要先認證過。

這邊的認證需要用公開被信任的 SSL Certificate,而大多數人應該會直接拿 AWS 提供的 ACM 來用:

With this change, when you add an alternate domain name using the AWS Management Console or the CloudFront API, you will now need to attach a certificate to the distribution to confirm that you have authorized rights to use the alternate domain name. The certificate must be valid and come from a publicly trusted Certificate Authority like AWS Certificate Manager which provides public SSL/TLS certificates for free.

申請 ACM 也需要確認身分,印象中沒記錯的話是透過 DNS 或是 e-mail 認證。

會有這個改變是因為有一個 DDoS 的攻擊手法可以「造成困擾」。在沒有認證就可以增加網域名稱的情況下 (假設是 assets.gslin.com),AWS 需要把不同帳號設定同一組 domain name (assets.gslin.com) 的 IP address 分開,這樣才能確保安全性。而 IPv4 address 是有限的,用很多帳號申請就有機會讓真正的 assets.gslin.com 擁有人想要用的時候沒有資源可以用。

其實在 Route53 也有類似的問題,但因為是個雞生蛋蛋生雞的問題,就更不好解決了,在 DNS 還沒設定好之前要怎麼確認身分是一個更頭痛的問題... e-mail 認證可能是一個方法,但流程上就多了不少步驟。

MTR 看每個點的 AS number 或是地區資訊

跟「Mac 上讓 SSH 走 Socks5 的方式」這邊也有點關係,在泰國時測試發現 MTR 可以除了標準的 traceroute 結果外,還可以另外拉出 AS number 或是地區資訊。雖然不一定準 (因為是靠 IP address 查的),但可以很方便取得這些資料加減參考用。

-z 可以拉出 AS number (雖然 manpage 裡面不知道在搞什麼 XDDD):

       -z, --aslookup
              MISSING

另外一個是 -y,也沒寫要怎麼用,但因為是標 n 所以可以猜是數字。實際測試可以看出跟 GeoIP 套件似乎有些相關...

-y 1 是 IP network 區段 (像是 168.95.0.0/16),而 -y 2 則是地區資訊 (像是 TW 或是 US),-y 3 則是哪個 NIC 管的 (像是 apnic),-y 4 是更新日期:

       -y n, --ipinfo n
              MISSING

配合 -b 可以同時看 hostname 與 IP address,這樣資訊就蠻完整的了。另外在 Mac 上的 Homebrew 編出來的 MTR 測不出這些功能,我暫時沒花時間去追,這邊主要都是拿 Ubuntu 上的版本測試的...

日本圍棋界使用 AWS 分析棋局的情況

看到「圍棋AI與AWS」這篇譯文,原文是「囲碁AIブームに乗って、若手棋士の間で「AWS」が大流行 その理由とは?」。

沒有太意外是使用 Leela Zero + Lizzle,畢竟這是 open source project,在軟體與資料的取得上相當方便,而且在好的硬體上已經可以超越人類頂尖棋手。

由於在 Lizzle 的介面上可以看到勝率,以及 Leela Zero 考慮的下一手 (通常會有多個選點),而且當游標移到這些選點上以後,還會有可能的變化圖可以看,所以對於棋手在熟悉操作介面後,可以很快的擺個變化圖,然後讓 Leela Zero 分析後續的發展,而棋手就可以快速判斷出「喔喔原來是這樣啊」。

網路上也有類似的自戰解說,可以看到棋手對 Lizzle 的操作與分析 (大約從 50:50 開始才是 Lizzle 的操作):

不過話說回來,幹壞事果然是進步最大的原動力... 讓一群對 AWS 沒什麼經驗的圍棋棋手用起 AWS,而且還透過 AMI 與 spot instance 省錢... XD