Home » Articles posted by Gea-Suan Lin (Page 4)

B612 字型

B 612 是小王子裡的星球,被拿來引用當作字型名稱了:「B612 – The font family」。

這是空中巴士設計給飛機上的系統用的,所以包括了「舒服」(長時間) 與「易讀」,算是某種以「安全」為考量的字體?

In 2010, Airbus initiated a research collaboration with ENAC and Université de Toulouse III on a prospective study to define and validate an “Aeronautical Font”: the challenge was to improve the display of information on the cockpit screens, in particular in terms of legibility and comfort of reading, and to optimize the overall homogeneity of the cockpit.

然後包括了 regular 與 monospace 兩種:

Git 的記錄已經 open source 一陣子了,拿來當 sans-serif 用一段時間看看好了...

Twitter 搬上 Google Cloud

Twitter 要搬上 Google Cloud Platform 了,而 Google 直接把這個消息用最漂亮的 url 發佈:「Twitter migrates data to Google Cloud to keep the world tweeting」。

裡面也提到了一些數字,像是 Twitter 使用的空間:

To keep processing massive amounts of data 24/7, the social media platform was expecting to transfer over 300 petabytes of data storage to the cloud.

另外實際用 mtr 跑,看起來 twitter.com 前面還是 Twitter 自家機房的 proxy,所以應該是後面的架構搬上去?

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞,但沒讀完就一直放著沒寫:「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題,對於 HTTP 重導的程式碼沒有處理好外部字串,在還沒修正的機器上用這個指令關閉 redirect,避免在修正的過程反而被 RCE 打進去:

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題,因為 HTTPS 連線用的程式碼又是另外一份,裡面不知道有沒有問題 (像是之前經典的 Heartbleed),所以應該還是會繼續爭吵吧...

TiDB 單機效能

TiDB 是一個支援分散式運算的資料庫,希望能夠完整地模擬 MySQL Protocol,而 Percona 試著測試 TiDB 在單機的效能,雖然測試的項目很簡單,但結果頗有趣的:「A Quick Look into TiDB Performance on a Single Server」。

Percona 觀察到的現象是 TiDB 對於單一 SQL query 支援多 CPU 運算 (MySQL 只會使用單 CPU),所以在高階的機器上,某些 SQL query 會快很多。而 OLAP 類型的 SQL query 也不錯,但常見的 OLTP 應用則慢不少:

Short version: TiDB supports parallel query execution for selects and can utilize many more CPU cores – MySQL is limited to a single CPU core for a single select query. For the higher-end hardware – ec2 instances in my case – TiDB can be 3-4 times faster for complex select queries (OLAP workload) which do not use, or benefit from, indexes. At the same time point selects and writes, especially inserts, can be 5x-10x slower. Again, please note that this test was on a single server, with a single TiKV process.

是個有趣的 drop-in...

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外,在「Preload Scripts」這邊看到的技巧,可以跟 browser 說明哪些資源比較重要,請儘快先下載:

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法,這個技巧應該用在會卡住頁面呈現的部分,確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面,理論上會更快:

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助,建議可以跑 A/B test 看看效果:

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

Travis CI 被併購...

Travis CIIdera 併購:「Travis CI joins the Idera family」。

沒聽過 Idera,而且其他的產品也沒聽過,可能要再多花點時間看看到底是什麼樣的公司... 然後再決定要不要整個跳槽到其他 CI 上,畢竟 CI/CD 這塊還是很吃信任問題,不光是 compliance 而已...

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明:「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護,但會使得維護的複雜度變高很多。

首先是被竄改的問題,APT 本身就有簽名機制 (參考「SecureApt」),即使 mirror site 被打下來也無法成功竄改內容,反而比起單純的 HTTPS 保護還好。

而對於隱私問題,由於內容是可以公開取得的,這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法),加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高),所以隱私的保護上其實有限。

而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack),APT 降低風險的解法是把時間簽進去,當用戶端發現太久沒更新時,就當作過期失效而提出警告。

就以上來看,把所有的 APT 伺服器都加上 HTTPS 的工程太浩大,而得到的效益太小。所以願意提供 HTTPS 的站台就提供,但主要的保護還是從本來的 SecureApt 機制上提供。

在 2019 年出的 PHP 5.6.40...

剛剛才注意到 PHP 5.6 在 2019 年還有新的版本:「PHP 5.6.40 Released」。

在「Supported Versions」可以看到 PHP 5.6 應該是在 2018 年年底就終止更新,看起來是 5.6.39 在 2018/12/06 出之後,把剩下的一包都累積起來,「原則上」後面不會有更新:

Please note that according to the PHP version support timelines, PHP 5.6.40 is the last scheduled release of PHP 5.6 branch. There may be additional release if we discover important security issues that warrant it, otherwise this release will be the final one in the PHP 5.6 branch.

不過看起來官方的態度是「儘量幫」,如果有太嚴重的漏洞還是會補... :o

Archives