把 YouTube 對 channel 與 user 的自動播放功能關掉...

YouTube 在 channel 與 user 頁面會自動播放會讓人覺得頗困擾 (頁面一打開就有聲音)，所以想要找看看有沒設定可以關掉... 找了之後發現很久前就有被問過，但是當時得到沒有這個功能的回答：「How do I DISABLE autoplay from other channels on my YouTube channel?」。

既然如此就只能找套件來解了... 目前是透過 Userscript 擋下自動播放，程式碼不長也蠻好懂的：「Disable YouTube Channel/User Home Page Video AutoPlay」。

這樣總算是不會被聲音搞到...

Browser, Computer, Murmuring, Network, Service, Software, WWWNo Comment

直接在 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 出現了...

Computer, Linux, Murmuring, OS, SoftwareNo Comment

HyperLogLog 與 Bloom Filter

看到 Facebook 在 Presto 裡增加使用 HyperLogLog 計算數量的能力，突然想到常常忘記這兩個拿準確度換速度的資料結構：「HyperLogLog in Presto: A significantly faster way to handle cardinality estimation」。

HyperLogLog (HLL) 是解決 Count-distinct problem 的資料結構，用很少的記憶體就可以給出一個誤差不大的值 (用 1.5KB 的空間處理十億等級的資料，誤差大約在 2%)，所以 Presto 利用這個資料結構引進了 APPROX_DISTINCT() 以及其他的函數，就很容易在 L2/L3 cache 裡運算，藉此大幅提昇速度。

Depending upon the problem at hand, we can achieve speed improvements of anywhere from 7x to 1,000x.

先前也提過 Reddit 也用 HLL 統計資料：「Reddit 在處理 Page View 的方式」。

Bloom Filter 也是在處理大量資料的問題，但這個資料結構的功能不太一樣，是給出「有沒有存在」，使用空間與誤差大約是 10 bits per key (1% false positive)，另外先前也有提到一些變形，可以提供其他功能。像是「Quotient filter」與「Cuckoo Filter：比 Bloom Filter 多了 Delete」。

Computer, Murmuring, ProgrammingNo Comment

所以要開始開發 CECPQ2 了...

CECPQ1 是 Google 在研究對抗量子電腦的演算法，作為測試用的演算法，曾經在 Google Chrome 的 54 beta 版 (2016 年) 存活過一段時間，最近又開始在開發新一代的演算法 CECPQ2 了，這次會是基於 TLS 1.3 上測試：「CECPQ2」。

CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.

目前對抗量子電腦的演算法好像都跟 Lattice 有關，找時間來補一下基礎理論... @_@

Browser, Computer, GoogleChrome, Murmuring, Network, Privacy, Security, Software, WWWNo Comment Cloud, Computer, Murmuring, Network, ServiceNo Comment

在 EC2 上面疊 IPsec

AWS 發了一篇關於在 EC2 上面疊 IPsec 的方式：「Creating an opportunistic IPSec mesh between EC2 instances」。

這個需求主要是因為 AWS 一直沒有保證在同一區的流量有加密 (包括了同一個機房的流量、同一個 AZ 但不同機房的流量，以及同一區跨 AZ 之間的流量)，甚至跨帳號間的 VPC Peering 都不保證有加密，只說「跟兩台 instance 之間的溝通相同」，用詞很小心 (參考「Amazon VPC FAQs」這邊的說明)：

Q. Is VPC peering traffic within the region encrypted?

No. Traffic between instances in peered VPCs remains private and isolated – similar to how traffic between two instances in the same VPC is private and isolated.

目前唯一有保證的是跨區的 Inter-Region VPC Peering 服務有加密：

Q. Is Inter-Region VPC Peering traffic encrypted?

Traffic is encrypted using modern AEAD (Authenticated Encryption with Associated Data) algorithms. Key agreement and key management is handled by AWS.

在 2013 年 Snowden 揭露的消息可以知道 Google 與 Yahoo! 的機房都被 NSA 盯上，截聽內部跨機房的流量：「How we know the NSA had access to internal Google and Yahoo cloud data」。

沒什麼道理 AWS 的就不被盯上，所以對於高度敏感的應用來說，還是會希望在 AWS 能對於離開建築物的流量提供加密。

但在這之前，只能透過自己補上加密機制來解決，也就是這篇在 EC2 上面疊 IPsec overlay network 的前提。

可以在文章裡看到使用了不少 AWS 自家的服務，避免需要自己架設 server 管理 (得自己處理 High Availability 的問題)。

裡面主要是用了 KMS 存放憑證，以及使用 Lambda 發每一台 EC2 instance 所需要的金鑰，這兩個都是直接拿 AWS 的服務，就省下不少事情了。

MurmuringNo Comment

AWS 的瑞典機房開了，那香港呢...

AWS 開了 Stockholm 區 (eu-north-1)：「Now Open – AWS Europe (Stockholm) Region」。

在「In the Works – AWS Region in Hong Kong」這邊宣佈香港區會在 2018 開放，現在只剩下兩個多禮拜的時間了。

可以看到 subdomain 已經準備好，但還沒上線 (查 ap-southeast-4 的 NS RR 是直接給 NXDOMAIN)：

;; AUTHORITY SECTION:
ap-southeast-3.amazonaws.com. 900 IN    NS      dns-01.amazonaws.com.
ap-southeast-3.amazonaws.com. 900 IN    NS      dns-02.amazonaws.com.

只好繼續等了...

AWS, Cloud, Computer, Murmuring, Network1 Comment

CloudFront 在北美增加了一堆節點...

CloudFront 在北美增加了一堆節點：「Amazon CloudFront announces ten new Edge locations in North America, Europe, and Asia」。

北美一口氣增開了八個，提升了 40% 的 capacity：

Amazon CloudFront announces ten new Edge locations, adding to our global presence. Eight of the new Edge locations are in North America: Houston, Texas (our first location in this city), Chicago, Illinois, Newark, New Jersey, Los Angeles, California, and Ashburn, Virginia. We also added an Edge location in Berlin, Germany, as well as one in Tokyo, Japan.

With this launch, CloudFront will increase its request processing capacity by up to 40%, on average, in the North American cities.

另外不怎麼意外的又增加了東京...

AWS, CDN, Cloud, Computer, Murmuring, Network, Service, WWWNo Comment

AWS 給 EBS 用的 Data Lifecycle Manager 在東京可以用了？

先前在「Amazon EBS Snapshot 支援 Lifecycle Management」這邊提到 AWS 設計了 Data Lifecycle Manager，讓 EBS 磁碟可以自動產生 snapshot 並且管理保留份數，可以當作某種備份機制。

七月公告當時只開放了少數幾區：

Availability – Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions.

剛剛發現在東京也已經可以用了？但好像沒看到有公告提過... 設下去看看會不會動好了。

AWS, Cloud, Computer, Murmuring, Network, Service1 Comment

HTTP/3 (QUIC) 的反面看法

這篇整理了 HTTP/3 (QUIC) 的反面看法，算是常見的疑慮都列出來了：「QUIC and HTTP/3 : Too big to fail?!」。

其實大多都是使用 UDP 而導致的問題：

  • 因為 UDP 導致 firewall 可能沒開，以及可能會需要等 timeout 走回 TCP 的問題。
  • 因為 UDP 變成很多事情在 userland 處理，而導致的 CPU 使用率比使用 TCP 的 TLS 1.2/1.3 高很多。
  • 因為 UDP 導致 amplification attack 的安全性問題，以及對應的 workaround 產生的頻寬議題。
  • 由於 UDP 會需要自己控制擁塞，等於是在 UDP 上面又重做了一次 TCP congestion algorithm，而且因為重作所以得考慮與 TCP 搶資源的公平性。

整篇文章算是整理了一般對 HTTP/3 的疑慮，之後如果有進展的話，可以再拿出來當 checklist 再確認有哪些有改善...

Computer, Murmuring, Network, Security, WWWNo Comment

Recent Comments

Archives

Blogroll