不吃電池的 HD Camera Streaming...

Hacker News Daily 上看到「Towards Battery-Free HD Video Streaming」這個,不使用電池僅靠反射產生訊號,可以達到 HD 畫質的 Camera Streaming (在原型機上測試可以跑出 720p/10fps):

Finally, we design a proof-of-concept prototype with off-the-shelf hardware components that successfully backscatter 720p HD video at 10 fps up to 16 feet.

而且畫質比想像中好很多,算是比「可用」的等級還高不少:

愈來愈多在研究用 backscatter 拼一些比較複雜的應用...

SmugMug 買下 Flickr

SmugMug 買下 Flickr,這應該算是好消息 (吧):「Exclusive: Flickr bought by SmugMug, which vows to revitalize the photo service」。

雙方的新聞稿是:「SmugMug acquires Flickr: Two passionate communities together at last.」與「Together is where photographers belong!」。

時代的眼淚啊... 還在交大的時候買了 Pro,後來被併進 Y! 後沒續約了。丟著直到 Instagram 可以同步上去時又有更新,然後 Instagram 停止分享到 Flickr 的功能後又改找 IFTTT 同步。

而本來做 Flickr 的那群人後來跑去做 Slack... (包括 Stewart ButterfieldCal Henderson XD)

來看看後續會有什麼改變... 第一波應該是帳號系統的轉移?然後再來是 pricing model 的改變?

MySQL 8.0 正式推出 (GA,General Availability)

Oracle 推出了 MySQL 8.0 (GA,General Availability):「MySQL 8.0 – Announcing GA of the MySQL Document Store」。在「What’s New in MySQL 8.0? (Generally Available)」這邊也花了一些篇幅介紹 MySQL 8.0 的新功能。

比較感興趣的是:

  • Descending Indexes
  • Information Schema (speed up)
  • Performance Schema (speed up)
  • INVISIBLE Indexes
  • Scaling Read/Write Workloads
  • Utilizing IO Capacity (Fast Storage)
  • Better Performance upon High Contention Loads (“hot rows”)

不過就實用性來說,效能的提昇還是最直接的... 接下來等 Percona 的人 porting 了。

廣告的 SDK 因為走 HTTP 傳輸而洩漏大量資料...

廣告走 HTTP 而且還帶了一堆敏感資訊,算是最近討論蠻熱烈的問題:「Leaking ads」。

而且還分析找出有哪些是超大的廣告 unencrypted domain,像是這樣:

不過裡面一堆都不熟悉的廣告業者,反倒是聯想的網域被抓出來了:

不過行動裝置上能控制的東西太少了... 裝廣告阻擋程式比較實際,iOS 上不 JB 應該是只有 VPN 的方案,而 Android 上的方案應該就比較多了,除了 VPN 以外有 /etc/hosts 甚至是 firewall solution。

OS X 接藍芽耳機要注意的地方...

Twitter 上看到 OS X 接藍芽耳機時的音質問題:

看了一些討論,看起來除了蘋果自己的耳機外,其他家的藍芽耳機不一定會開 AAC 或是 aptX。雖然現在沒有其他家的藍芽設備,但以後如果買了要注意一下...

Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容

Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊:

現在要看這個資訊比較麻煩,之後可以在瀏覽器裡直接讀就會簡單一些了...

話說回來,Let's Encrypt 上個月也支援 SCT 了:「Engineering deep dive: Encoding of SCTs in certificates」,不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例),但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的,沒看到 SCT 資訊... 要等下一次的 renew 了。

Trac 1.2 上惡搞 TracTicketReferencePlugin 讓他會動...

TracTicketReferencePlugin 是個 Trac 上設定 ticket 之間關聯性的 plugin,與子母票有比較強烈的關係不同,有些人喜歡把相關的資料都掛在這邊。先前用都是在 Trac 1.0 上用,也沒什麼問題,最近在 Trac 1.2 上跑發現直接有 js error...

原因是 TracTicketReferencePlugin 用到 jQuery.live(),而這個函式在 jQuery 1.7 被宣告 deprecated,在 jQuery 1.9 被正式拔掉了。而 Trac 1.0 用的是 jQuery 1.7,所以不會有問題;Trac 1.2 用的是 jQuery 1.12,於是就爛掉了...

剛好就是昨天,有人在作者的 repository 上發 issue 出來 (另外也提供了 patch):「t2y / trac.plugins.ticketref / issues / #9 - JavaScript errors with Trac 1.2 — Bitbucket」。雖然 patch 本身不算難,但我實在懶的查 Mercurial 的操作,於是決定用 workaround 解...

想法是讓 jQuery.live() 會動,這點在 jQuery 官方出的 Migrate 就可以達到 (需要用 1.4.1 版,而不是 3.0.1 版),於是第一步就是在 site.html 內直接先下手為強,讀 jQuery 後馬上讀 Migrate:

  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    <script src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
    <script src="https://code.jquery.com/jquery-migrate-1.4.1.min.js"></script>
    ${select('*|comment()|text()')}

但 Trac 還是會再載入一次的 jQuery 而蓋過去,所以我們要讓 Trac 不會載入,在 trac.ini 內的 jquery_location 設定讓他讀一個空的 js 檔:

jquery_location = site/null.js

然後生一個空的 trac/htdocs/null.js 讓他讀。

最後開一張票追蹤,看什麼時候官方放新版,再把這串 workaround 拔掉...

nginx 穩定版 1.14.0 出版

Twitter 上看到 nginx 穩定版 1.14.0 出了:

CHANGES-1.14 可以看到 1.12 到 1.14 中間多了哪些功能,我比較注意的是:

  • 引入了 TLS 1.3 關鍵字。(因為還沒進 Standard Track,不能直接說支援了...)
  • 支援 HTTP/2 Push。
  • 引入 gRPC 相關的功能。

看看 Ubuntu 18.04 會不會直接上這個版本,另外就是等 PPA 了...

Cloudflare 的 jpegtran 在 ARM 上面的表現

Cloudflare 花了不少力氣在 ARM 的伺服器上 (可以參考「Cloudflare 用 ARM 當伺服器的進展...」,或是更早的「Cloudflare 測試 ARM 新的伺服器」這篇),最近在 ARM 上發現 jpegtran 的效能不是太好,花了不少力氣最佳化,發現有意外收穫:「NEON is the new black: fast JPEG optimization on ARM server」。

他們設的低標是讓每個 core 的效能大約在 Xeon 的 50%,但發現只有 26% 左右的效能:

Ideally we want to have the ARM performing at or above 50% of the Xeon performance per core. This would make sure we have no performance regressions, and net performance gain, since the ARM CPUs have double the core count as our current 2 socket setup.

In this case, however, I was disappointed to discover an almost 4X slowdown.

而他就想到這些圖形運算的程式應該早就在使用各種 SIMD 指令集加速,於是作者就想到,把 SSE 的最佳化部份 porting 到 ARM 上面的 NEON 說不定會有很大的幫助:

Not one to despair, I figured out that applying the same optimizations I did for Intel would be trivial. Surely the NEON instructions map neatly to the SSE instructions I used before?

而 porting 完後重新測試發現達到了 66% 的效能,已經超過本來的目標... 另外在批次處理中,也比 Xeon 快了:

繼續發研究時又發現 NEON 有一些在 SSE 沒有的指令 (沒有相似功能),也許能提供更進一步的加速:

While going over the ARMv8 NEON instruction set, I found several unique instructions, that have no equivalent in SSE.

如果再把這些指令實做出來,會發現單 core 的效能已經到 Xeon 的 83%,而批次的速度又提昇了不少:

最後是整台伺服器都跑滿時的測試,會發現整台的效能差不多 (其實 ARM 的版本還贏一些),但吃電量不到一半,而就算只拿他們常態在跑的 4 workers 來看 (應該是為了 latency 問題),用電效率來到 6.5 倍:

With the new implementation Centriq outperforms the Xeon at batch reduction for every number of workers. We usually run Polish with four workers, for which Centriq is now 1.3 times faster while also 6.5 times more power efficient.

這篇在提醒之後在 ARM 上寫最佳化時,不要只從 SSE porting 到 NEON,要多看一下有沒有其他指令集是有幫助的...

Archives