Dropbox 免費版限制三個裝置更新...

Dropbox 決定限制免費版的裝置數量,最多只能有三個裝置同步:「Dropbox adds three-device limit for free users」,對應的頁面是「Is there a limit to the number of devices I can link to my account?」。

既有的裝置不受限,但無法再增加:

If you're a Basic user and you linked more than three devices prior to March 2019, all of your previously linked devices will remain linked, but you can’t link additional devices.

另外一個選擇是付費版,最低是 1TB USD$9.99/month (年繳是 USD$99/year)。

看起來像是養肥了要殺,不過這個領域相關的技術應該是夠成熟,而且也不會用到什麼特別的功能,應該會去看看其他平台的情況,像是 SyncpCloud

其中 Sync 有免費版 (空間限制 5GB,付費版 500GB USD$49/year),不過官方不支援 Linux,有人用 Wine 跑過,但據說穩定性與效能都不太好:「Sync.com in Linux」。

pCloud (500GB EUR$47.88/year) 也是剛剛提到在 Linux 上跑 Sync 的人後來測試的服務,官方有支援 Linux (看起來是透過 AppImage 包裝),也許可以測試看看。

另外一個是自己一直都有在用的 Syncthing,不過設定同步的操作上只有 web interface,而且因為是信任架構,需要多台互相設定,沒那麼方便...

只透過 SSH 重灌系統的 takeover.sh

看到 marcan/takeover.sh 這個專案:

Wipe and reinstall a running Linux system via SSH, without rebooting. You know you want to.

還蠻有趣的專案 (實用性質應該不高,主要是展示可行性),程式很短,就一個 C program 以及一個 shell script,但裡面用到很多外部工具 (像是 BusyBox 的執行檔),作者建議有興趣的人可以先用 virtual machine 玩...

這個專案讓我想到更複雜的 Depenguinator,把 Linux 灌成 FreeBSD 的專案,不過這個專案也已經很久沒更新了...

Percona 對於 PostgreSQL 使用 HugePages 的評論

開頭我先說一下我的想法,我對於 Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度,因為他先前在「Benchmark PostgreSQL With Linux HugePages」這篇做的 benchmark 就有奇怪的結果,但卻給不出合理的原因,甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋:

Hi,

A lot of interesting results here…

1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive

2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled

3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.

這次看到「Settling the Myth of Transparent HugePages for Databases」這篇,也是在討論 Linux 的 HugePages 對 PostgreSQL 帶來的影響,同樣馬上又看到奇怪的東西...

首先是標示與圖片不合:

Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)

Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)

不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB),當做是標錯就好。

但這樣又跑出一個奇怪的結果,48GB 的資料量比較小,TPS 大約是 35K/33K/41K,但 112GB 資料量比較大,卻可以達到 39K/43K/41K~42K,反而比較快?我暫時想不到什麼理由...

整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch,先不管),其中 pgbench 跑了 10 mins 與 60 mins 的版本,但是 sysbench 只跑了 10 mins 的版本?這是什麼原因...

另外還是有些情況是打開 HugePages 比較快的 (sysbench 的 64 clients),如果以直覺來說的話,我反而還是會打開 HugePages (yeah 純粹是直覺),我現在比較想知道他會在 Percona 裡面待多久...

保護 Linux 的檢查清單...

trimstray/the-practical-linux-hardening-guide 這邊看到保護 Linux 系統的方式,列成清單:

This guide details the planning and the tools involved in creating a secure Linux production systems - work in progress.

從實體的開始講,然後 BIOS,再來是 OS 層,接下來是基本服務,再來到應用程式,一般人做的到的該涵蓋的都有涵蓋到了...

不過在一般情況下要全部都完成不太可能 (通常是人太懶),但可以當清單掃一輪挑著做,加強系統的安全性...

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 機制上提供。

直接在 Ubuntu 的 Unity 上直接計算

Mac 上還蠻常直接在 Spotlight 上打簡單的算式看計算的結果,但我的桌機是在 Ubuntu 上,沒看到這個功能,所以都是用 search engine 幫忙算 (以前是 Google,現在是 DuckDuckGo),但還是想要找個類似的東西看看能不能在本機處理掉...

後來在「Can you get something like Unity Dash--especially the instant calculator--in other distros?」這邊看到 screenshot 的效果應該就是我想要的:

不過發現預設好像不會開 (跟文章裡面提到的不太一樣),所以又找了一段時間,發現在「How to permanently enable in-dash calculator in 13.10」這邊,River Satya 提到的方式是我要的:

  • Install dconf-editor sudo apt install dconf-editor
  • Run it dconf-editor
  • Open com.canonical.unity.lenses
  • Add info-calculator.scope to the always-search list
  • Profit!

改完後就會像 screenshot 出現了...

Ubuntu 撥 HiNet PPPoE 時會因為 MTU 而導致有些網站連不上

之前用 HiNet 固定制 (不需要 PPPoE,直接設 IP 就會通的那種),跑起來順順的也沒麼問題,最近剛好合約滿了就打算換成非固定制 (需要撥 PPPoE 才會通),結果換完後發現有些網站常常連不上 (不是一直都連不上),但只要設了 proxy.hinet.net (今年年底要停止服務了) 或是改從 cable 線路出去就正常。

測了不少設定都沒用 (像是改 tcp timestamp 設定,或是 sack 之類的設定),後來發現 MTU 的值不太對,用 ifconfig 看發現我的 ppp01500 而不是 1492,直接先 ifconfig ppp0 mtu 1492 改下去測,發現本來不能連的網站就通了...

(補充一下,我看了 Windows 的設定是 1480,所以也沒問題,但不知道怎麼算的...)

查了一下 MTU 相關的問題,發現在「wrong mtu value on dsl connection」這邊有討論到。裡面提到的 workaround 是到 /etc/NetworkManager/system-connections/ 裡找出你的 PPPoE 設定檔,然後在 ppp 區域的裡面寫死 mtu 參數:「mtu=1492」(這邊的 1492 是從 1500 bytes 扣掉 PPPoE 的 8 bytes 得出來的),不過我測試發現在修改設定檔時會被改回來,加上測試發現沒用,只好自己寫一個 /etc/network/if-up.d/pppoe-mtu 惡搞了:

#!/bin/sh -e

if [ "$IFACE" != "ppp0" ]; then
        exit 0
fi

/sbin/ifconfig ppp0 mtu 1492

放進去後要記得 chmod 755

從 ticket 上面看起來還是沒有解 (2009 年就發現了),看起來 PPPoE 不是絕對多數而且又有 workaround,短期應該不會修正...

Travis CI 將轉移到 VM-based 環境

Travis CI 宣佈了將目前 container-based 的環境轉移到 VM-based 的時程:「Upcoming Required Linux Infrastructure Migration」,裡面有提到十月初的時候的文章「Combining The Linux Infrastructures」。

看起來是因為安全性的考慮,container-based 的環境必須在指定 sudo: false 的情境下才能使用。如果需要 root 權限一定會丟到 VM-based 的環境跑。現在看起來 Travis CI 不打算維護 container-based 環境了,所以整個轉移到 VM-based 的環境...

另外一個方向應該是 Google 之前提出來的 gVisor 專案 (參考「Google 推出 gVisor 強化 Container 的安全性」),不過看起來相容性又是個問題...

Linux Kernel 4.20 修正了一卡車 Intel CPU bug,然後效能掉光了...

看到「Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower」這篇測試了目前還在 RC 的 4.20.0,可以看到 AMD 的效能沒有太大影響,但 Intel i9 的效能掉了很嚴重:

從說明可以看到有測出 30%~50%:

This ranged from Rodinia scientific OpenMP tests taking 30% longer to Java-based DaCapo tests taking up to ~50% more time to complete to code compilation tests taking measurably longer to lower PostgreSQL database server performance to longer Blender3D rendering times.

另外在其他 Intel CPU 上測試也發現不是只有 i9 有影響,低階的機器也是:

Those affected systems weren't high-end HEDT boxes but included a low-end Core i3 7100 as well as a Xeon E5 v3 and Core i7 systems.

透過 bisect 有找到是哪個 commit 造成的:

That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.

但這又是屬於 security patch,不太能關... 加上自從 MeltdownSpectre 後,讓安全研究人員發現了全新的天地,之後應該只會愈來愈慘 :o

Travis CI 居然記得要支援 16.04 了...

看到 Travis CI 的「Ubuntu Xenial 16.04 is available!」這篇讓人痛哭流涕啊... 五年的支援期偷已經過了兩年半,總算想起來要推出了 16.04 的 image 了?還是是因為 14.04 剩不到半年?不然好像很有可能繼續撐...

下一次要出 18.04 又是兩年後了嗎...