Home » Posts tagged "diff"

comm 的用法...

最近在 Twitter 上看到不少 shell 指令的說明,這則 tweet 是講 comm 這個指令:

1 是只有第一個檔案有的內容,2 是只有第二個檔案有的內容,而 3 是兩者都有的內容,而且檔案內容需要排序過。

當你 -1 時表示幹掉 1 的部份,-2 代表幹掉 2 的部份,-3 代表幹掉 3 的部份,然後可以疊起來用... 不過平常還是用 diff 比較多,每次看到 comm 的說明都是玩過再熟悉一下,然後就丟著 XD

Google 再次改善 Android 的 APK 更新,讓下載的量更小

Google 的人再次更新了演算法,將下載的量再次減少,從本來的 47% 降到 65%:「Saving Data: Reducing the size of App Updates by 65%」。

今年七月的時候,更新演算法導入了 bsdiff,使得本來要抓整包 APK 的量,變成抓 diff 的部份,這使得下載的流量降了 47%:「Improvements for smaller app downloads on Google Play」。

Using bsdiff, we were able to reduce the size of app updates on average by 47% compared to the full APK size.

現在則改成不直接對 APK 做 diff,而是對未壓縮的檔案做,再把差異包起來,則可以降到 65%:

Today, we're excited to share a new approach that goes further — File-by-File patching. App Updates using File-by-File patching are, on average, 65% smaller than the full app, and in some cases more than 90% smaller.

主要的原因在於 APK 的壓縮使用的 DEFLATE 演算法對於變更非常敏感,改變一個字元就會讓後續整串都改變,導致差異很大而跑 diff algorithm 的效果不好:

用 File-by-File 的好處主要來自於是對未壓縮的檔案比較差異,這代表沒有變動的檔案完全不會進來攪和,而對 binary 檔案的效果也比較好 (大部份的程式碼還是一樣)。不過這對於已經有壓縮的圖片的效果就比較差了,這也是 APK 一般肥大常見的原因。

有兩件事情值得注意的,一個是 Google 的人為了使用者體驗,只有在 auto update 時才會走 File-by-File 的更新,主要原因是 File-by-File 的解開速度慢不少:

For now, we are limiting the use of this new patching technology to auto-updates only, i.e. the updates that take place in the background, usually at night when your phone is plugged into power and you're not likely to be using it. This ensures that users won't have to wait any longer than usual for an update to finish when manually updating an app.

另外一個是,這個新方式讓 Google 每天省下 6PB 的流量,如果流量都是平均打散的話,大約是 600Gbps:

The savings, compared to our previous approach, add up to 6 petabytes of user data saved per day!

這種規模改善起來很有感覺 XDDD

Facebook 備份 MySQL 資料並且確認正確性的方法

Facebook 再多花了一些篇幅數對於 MySQL 資料備份以及確認正確性的方法:「Continuous MySQL backup validation: Restoring backups」。

首先是 Continuous Restore Tier (CRT) 這塊,可以看到他們在這塊很仰賴 HDFS 當作備份的第一層基地,包括了 Full logical backups (用 mysqldump)、Differential (diff) backups 以及 Binary log (binlog) backups (stream 進 HDFS)。

另外上了 GTID,對於後續的處理會比較方便:

All of our database servers also use global transaction IDs (GTIDs), which gives us another layer of control when replaying transactions from binlog backups.

在 CRT 這塊可以看到其實是拿現成的工具堆起來,不同單位會因為規模而有不同的作法。真正的重點反而在 ORC Restore Coordinator (ORC) 這塊,可以看到 Facebook 開發了大量的程式將回復這件事情自動化處理:

在收到回復的需求後,可以看到 Peon 會從 HDFS 拉資料出來,並且用 binlog replay 回去:

Peons contain all relevant logic for retrieving backups from HDFS, loading them into their local MySQL instance, and rolling them forward to a certain point in time by replaying binlogs. Each restore job a peon works on goes through these five stages[.]

也是因為 Facebook 對 MySQL 的用量大到需要自動化這些事情,才有這些東西...

MediaWiki 的 EmailDiff 套件

先前 MediaWiki 所提供的「變更通知」都只有在信件裡「通知」,而沒有在信件裡列出「改變的內容」,這使得讀信的人要再點進去看... (於是就懶的點了)

而前陣子看到有人寫了 extension 來輸出 diff,解決了這個問題:「MediaWiki extension EmailDiff: notification emails improved」。


Version differences:
@@ -846,5 +887,3 @@
 In cattle, temperament can affect production traits such as carcass and meat 
 quality or milk yield as well as affecting the animal's overall health and 
-reproduction. Cattle temperament is defined as "the consistent behavioral and physiological 
-difference observed between individuals in response to a stressor or environmental 
+reproduction. If you succeed in tipping a cow only partway, such that only one 
+of its feet is still on the ground, you have created lean beef. Such a feat is 
+well done. Naturally, being outside, the cow is unstable. When it falls over, 
+it becomes ground beef. Cattle temperament is defined as "the consistent behavioral 
+and physiological difference observed between individuals in response to a stressor or environmental 
 challenge and is used to describe the relatively stable difference in the behavioral 
 predisposition of an animal, which can be related to psychobiological mechanisms.


diff-so-fancy 工具

Hacker News Daily 上看到的工具:「diff-so-fancy」。

光是從 screenshot 仔細看,會發現漏掉了一些 minus 與 plus 的資訊 (中間有一段應該要顯示 -document 與 +this.element, false 的部份,只顯示了 plus 的部份),有可能是 bug 也有可能是 feature。

另外對於已經讀習慣 diff 輸出結果的人,反而要另外學習,至於這個 learning curve 值不值得就見仁見智了...

把 icdiff 包成 PPA...

看到「一个能并列高亮显示文件比较结果的小工具 icdiff」這篇的介紹,順便複習一下 PPA 要怎麼包。


平常在用 diff 都會加上參數啊,像是我習慣用 -ruN,如果再加上顏色的話其實並不會比較難讀?而且現在最常用 diff 的地方是在 git 環境下用,會因為 color.ui 的設定自動支援色彩...

這是 icdiff 官方提供的 screenshot:

就給大家參考看看了 :o

用 git log 的 -S 與 -G 找變更記錄

符合 blog 副標題的一篇文章。

之前是拿 BBS 看板來存動畫的記錄,不過自從跑在 FreeBSD 32bits 上的 BBS code 一直沒辦法轉移到 Ubuntu 64bits,就放棄用 BBS 看板管動畫記錄了...

現在是拿 Git 來存動畫記錄,後來發現內建的 git log 搜尋起來比 BBS 方便太多,就回不去了...


$ git log -S '魔法戰爭' --pretty=%h | xargs -n1 git show
commit 9a6af4ec77561777b854a7ea44da29e197a9dcc2
Author: Gea-Suan Lin <gslin@gslin.org>
Date:   Mon Apr 7 00:55:49 2014 +0800


diff --git a/Anime.txt b/Anime.txt
index 080f94a..cd21e14 100644
--- a/Anime.txt
+++ b/Anime.txt
@@ -42,4 +42,3 @@ Z/X IGNITION                            e01
 銀之匙 Silver Spoon 第二季              e04
 鬼燈的冷徹                              e05
 魔女的使命                              e04
-魔法戰爭                                e11
commit 856a27ab4071fb19ca58de3725cdedf53815894b
Author: Gea-Suan Lin <darkkiller@gmail.com>
Date:   Mon Feb 10 04:46:57 2014 +0800


diff --git a/Anime.txt b/Anime.txt
index ddb11ea..e5995eb 100644
--- a/Anime.txt
+++ b/Anime.txt
@@ -22,3 +22,4 @@ WIZARD BARRISTERS~弁魔士賽希爾         e01
 偽戀                                    e02
 天才麻將少女 全國篇                     e05
 鬼燈的冷徹                              e05
+魔法戰爭                                e04

-S 只會列出「出現」與「消失」的時候,而且 -S 後面接的是 string 而非 regex。

如果要找所有與「魔法戰爭」相關的變更,則改用 git log -G,要注意的是後面接的是 regex:

 $ git log -G '魔法戰爭' --pretty=%h | xargs -n1 git show

Git 超好用的... XD