0.x 版的 ZeroVer

Hacker News Daily 上看到「ZeroVer: 0-Based Versioning (0ver.org)」這個討論,原網站在「ZeroVer: 0-based Versioning」這邊。

這應該是從 Semantic Versioning 出現 (看起來是 2009 年?) 而且被廣泛應用後的現象,就是大家都不想負責 XDDD

在 Semantic Versioning 裡面有提到 0.x 版的特殊性,也就是什麼都不保證:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

因為 Semantic Versioning 被廣泛應用後,這個特性也深受開發者喜愛 (即使軟體變得很成熟),於是 ZeroVer 這個站台就整理了一堆仍在使用 0.x 的軟體...

其實我覺得這樣很好,像是 HashiCorp 如果決定把軟體推出 1.0 版 (最近應該是 Terraform 的 1.0),表示他們對這個產品有一定的信心了,不然都還在摸索開發階段...

0.x 算是讓開發者可以很有信心的跟大家講「我沒信心」的方式 XD

Chrome 與 Chrome OS 最近不會更新新功能

這邊看到的消息,ChromeChrome OS 會避免在最近推出新功能,以維持軟體的穩定性,最近更新的主力會放在安全性上:「Google halts upcoming releases of Chrome and Chrome OS to keep things stable for everyone working from home」。

報導引用自 Twitter 上的宣佈:

呃,突然想到 Windows 的更新情況...

JavaScript 的 sort 變成 stable

看到「Stable Array.prototype.sort」這篇在講 JavaScript 規格書裡的 sort...

本來 JavaScript 的規格書裡,各種 sort 都沒有保證 stable,而在「[Normative] Make Array.prototype.sort stable #1340」與「[Normative] Make %TypedArray%.prototype.sort stable #1433」這兩個地方則有了變化,提案在規格裡加入 stable 的要求,可以減少開發者因為不知道 unstable 而造成的問題...

Firefox 則是很久前就決定使用 Merge sort 了 (看了一下,當時還在從 Firebird 轉換名稱到 Firefox 的時期):「Array.sort isn't a stable sort (switch to MergeSort)」。

另外這篇也剛好提到了 V8 使用 Timsort 當作 stable sorting algorithm,之前就有看到但發現沒在 blog 上提過...

Timsort 是 1993 年發明出來的演算法,與 Merge sort 的情況類似,除了 stable 外,還可以保證最差的情境下的時間複雜度是 O(n*log(n))

Timsort is a hybrid stable sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data.

這個演算法的重點是善用已經排好的子序列,藉此降低記憶體操作次數而提昇效能,符合真實環境裡常見到的資料:

The algorithm finds subsequences of the data that are already ordered, and uses that knowledge to sort the remainder more efficiently.

除了 V8 採用這個演算法以外,其他常見的包括了 PythonAndroid 上的 Java SE:

Timsort has been Python's standard sorting algorithm since version 2.3. It is also used to sort arrays of non-primitive type in Java SE 7, on the Android platform, in GNU Octave, and Google Chrome.

Google Chrome 68,第一個將所有 HTTP 站台都標成 Insecure 的版本

Google 在 stable channel 發布了 Google Chrome 68,這是 Chrome 第一個將所有 HTTP 站台都標成 insecure 的版本:「Stable Channel Update for Desktop」。取自二月時的圖:

文章內也說明了這個改變:

In Chrome 68, Chrome will show the “Not secure” warning on all HTTP pages. We announced this in a blog post published on February 8th on Google’s Chromium and Online Security blogs.

雖然之前 Google 一直在推動,但應該還是很多單位沒在管...

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 了...

Google Chrome 對 Symantec 全系列憑證的不信任計畫

Google Chrome 前陣子整理了一份對 Symantec 憑證的不信任計畫:「Chrome’s Plan to Distrust Symantec Certificates」。

這包括了一卡車的品牌,像是 ThawteVeriSignGeoTrustRapidSSL,不過 Equifax 跟 Symantec 的關係我沒查到...:

Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.

反正整個計畫會在 Google Chrome 70 推出時告一段落 (變成完全不信任),會是 2018/09/13 (預定時間) 與 2018/10/23 (預定時間) 在 beta channel 與 stable channel 上推出。

中間比較重要的時間點是 2018/03/15 (預定時間) 與 2018/04/17 (預定時間),Google Chrome 66 在 beta channel 與 stable channel 上推出,這個版本不會信任 2016/06/01 前發出的憑證:

Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.

整個計畫的時間軸清楚多了...

nginx 1.10.2

之前在「谈谈 Nginx 的 HTTP/2 POST Bug」這邊提到了 nginx 的一個 bug:「當 HTTP/2 的第一個 request 是 POST 時連線會失敗」的問題,這個問題在 mainline 版本的 1.11.0 解決了,但 stable 版一直沒有出新版 back-porting 回來。

而剛剛看到 1.10.2 將 http2_body_preread_size 從 mainline 版本弄回來解決了:「[nginx-announce] nginx-1.10.2」。

*) Change: HTTP/2 clients can now start sending request body
   immediately; the "http2_body_preread_size" directive controls size of
   the buffer used before nginx will start reading client request body.

然後剛剛發現 Ondřej Surý 老大分別弄出了 nginx (stable 版本) 與 nginx-mainline (mainline 版本) 的 PPA,所以也可以考慮可以直接換到 mainline 上?這樣也是個方法...

關閉 Google Chrome 49 的平滑捲動

在這次 Google Chrome 的「Stable Channel Update」裡引入了平滑捲動,在 comment 的地方有人提出解法,可以在 chrome://flags 裡找 disable-smooth-scrolling 關掉後重開 Google Chrome:

You can disable it here: chrome://flags/#disable-smooth-scrolling

另外一個 bug 是跑出一堆 extension icon 要重新蔵:

Hiding extensions needs to be made available again.

另外這次的安全更新有很多是透過「AddressSanitizer, ThreadSanitizer, MemorySanitizer」與「Control Flow Integrity」這兩個專案所找出來的。

裝 Ubuntu One...

Ubuntu One 是個類似 Dropbox 的軟體,有 5GB 免費空間可以用。

看到「Ubuntu One Mac Client Out of Beta, Now Stable」之後跑去裝 Mac 版,發現 Mac 版上的安裝介面跟 Mac 的風格完全不一樣... (很突兀,有種看到沒有 CSS 的 HTML 的感覺...)

裝完後開起來在這個畫面跑很久:

完成後的畫面:

另外在安裝完以後 Finder 不會出現 Ubuntu One 的側邊欄,對於第一次用的人應該會覺得有點茫然...

設定畫面長這樣:

那個配色與圓角框感覺起來好糟糕 XDDD

反正都裝起來了,就測試看看吧,晚點在 Ubuntu 上也跑起來看看是不是配色會比較搭?

Ubuntu 上的 Chromium Stable Channel 與 Dev Channel

Ubuntu 12.04 上的 Chromium 一直都是 18.0 版,而 "Chromium Builds" team 也沒在更新了...

過一陣子想起來就會去找一下,結果剛剛發現有人在 Launchpad 上面丟出來了:「New Chromium Stable And Development PPAs For Ubuntu 12.04」,有兩個版本,一個是 stable (目前是 21.0),一個是 dev (目前是 23.0)。

而舊的 repository 可以用 apt-add-repository -r 移除,然後再跑 apt-get update 更新。