Home » 2018 » February

加州在四月將會開放無人自駕車上路了...

TechCrunch 看到加州要開放自駕車上路了:「California to allow testing of self-driving cars without a driver present」。

California’s Department of Motor Vehicles established new rules announced Monday that will allow tech companies and others working on driverless vehicle systems to begin trialling their cars without a safety driver at the wheel. The new rules go into effect starting April 2.

不過不是完全獨立運作,而是有附加條件,讓遠端的控制中心可以在必要時介入:

This doesn’t mean test vehicles will be out there on the roads without any kind of human intervention backup – the DMV will require that those testing autonomous cars without a driver present have a dedicated communications channel that ties the car to a remote operator, who can take over if needed. The cars will also need to be hardened against cyber attacks and be able to provide their owner and operator info to any other parties in the event of an accident.

馬上想到刷機 JB... XD

Amazon RDS 宣佈支援 PostgreSQL 10

Amazon RDS 宣佈支援 PostgreSQL 10 了:「PostgreSQL 10 now Supported in Amazon RDS」。而且 AWS 這次推出的還包括了 10.1 的 patch:

As of version 10, PostgreSQL no longer uses three-part version numbers, and is shifting to two-part version numbers. This release includes all patches from the PostgreSQL 10.1 minor version.

10 的第一個版本是去年十月初 (在「PostgreSQL 10 Released」這邊可以看到),10.1 是去年十一月初 (在「PostgreSQL 10.1, 9.6.6, 9.5.10, 9.4.15, 9.3.20, and 9.2.24 released!」),現在二月底,所以延遲大約是三個多月的時間...

10.2 是二月初,不知道會多久...

Let's Encrypt 的 Wildcard Certificate 將會再延...

先前有提到 Let's Encrypt 的 Wildcard Certificate 從一月延到二月底 (表訂 2/27,參考先前的「Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出」這篇),今天想說歐美的時區也差不多要過完 2/27 了,結果翻資料發現在「ACMEv2 and Wildcard Launch Delay」這邊又宣佈延期了,這次也不給時間了 XDDD

主要是 TLS-SNI 認證方式的前提有問題,導致 Let's Encrypt 臨時調度人力處理這個包 (可以參考「2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure」這篇,裡面有提到共用產生的問題假設):

The biggest reason for this delay is the recent TLS-SNI deprecation. This unexpectedly pulled most engineering resources away from ACMEv2 and wildcard support for approximately two weeks.

然後 2/27 的說明提到目前是沒什麼大問題,但目前還在 QA 階段,然後目前先不給 release date:

Feb 27 Update: There are no known major issues with the ACMEv2/wildcard test endpoint. ACMEv2 and wildcard support quality assurance is continuing. No release date to announce yet.

就只能繼續等了... XD

Trac 1.2 裡 datepicker 每個禮拜的第一天改成星期天

Trac 1.0 搭配舊的 DateFieldPlugin 時,預設每週的第一天會是星期一,但這個設定可以在 trac.ini 內用 first_day 參數調整,像是這樣:

[datefield]
format = ymd
separator = -
first_day = 0

但在 Trac 1.2 在 trac.ini 裡就沒有提供設定讓人調整了... 而由於 Trac 是用 jQuery UIDatepicker,在這個套件裡有提供方法讓人調整,所以解決的方向變成在 site.html 內用 JavaScript 處理,把這段程式碼塞到 JavaScript 的區段內就可以了:

// Datepicker
jQuery.datepicker.setDefaults({firstDay: 0});

一整個繼續惡搞中... 然後把 wiki 上的 Trac 條目也更新上去。

Trac 1.2 的 Due Date...

在先前的文章提到了把自己在用的事件管理系統 Trac 從 1.0 升級到 1.2,然後 Due Date 的設計改變了:「Trac 1.1 增加的 time 欄位,以及 Due Date 資料的轉移」、「總算把手上的 Trac 1.0 升級到 1.2 了...」。

Trac 1.2 的資料型態是在底層存 unix timestamp 的變形 (乘以 1000000,然後前端補上 0 存成文字),這幾天用下來才發現一些以前沒遇到的問題。

一開始轉到 Trac 1.2 是設成 date,但意外的發現 (因為伺服器時間不是 UTC),不同時區的使用者在更新 ticket 時,系統會判定 Due Date 有變動而產生變更記錄,想了一下就改用 datetime 來處理這個問題。

用了 datetime 一陣子後,才發現先前的公司遇到的情境中,時區差異都很小,所以不會有 Due Date 理解上的問題 (像是從 +7 到 +9 的時區),如果今天是美國西岸跟台灣互相合作的話,只用 date 就會產生很明顯的理解問題了...

算是這陣子用 Trac 1.2 而對 Due Date 設計有不一樣的理解...

用 pipsi 管 Python 的 command line 工具...

在「My Python Development Environment, 2018 Edition « Jacob Kaplan-Moss」這邊看到 Python 開發有哪些工具可以用 (介紹了三個),其中管理不同 Python 版本的 pyenv 用一陣子了,另外兩個則是之前沒用過...

pipsi 是將套件用 virtualenv 包起來,讓使用者在用的時候不會受到其他環境的干擾。我是拿來跟系統的 python3 (目前在 Ubuntu 16.04 上是指到 3.5.1) 使用,所以安裝 pipsi 時先切到 system 再透過 python3 安裝 (讓他偵測到系統的 python3):

$ pyenv shell system
$ which python3
$ curl https://raw.githubusercontent.com/mitsuhiko/pipsi/master/get-pipsi.py | python3

接著把 PATH 參數設好後 (設到 .bashrc 或是 .zshrc 之類的檔案),重新開一個 terminal 或是 shell (讓路徑生效),再把 awscli 裝進去:

$ pipsi install awscli

這樣這些工具就會吃系統的 python3 了...

測試 TPUv2 的 C/P 值

有人用相同演算法實際測試 Google 的 TPUv2 與 NVIDIATesla P100 的 C/P 值了:「Benchmarking Google’s new TPUv2」。

如果以 ResNet-50 當作計算的演算法,可以看到其實 C/P 值的差距沒有想像中大。主要原因是 GPU 可以使用較低的精度計算以加快速度,而非 Google 之前新聞稿故意使用較高精度比較 (TPU 使用 8-bit matrix engine,所以 GPU 使用較低的 fp16 版本比較會比較有參考價值):

真正的差異是在 LSTM

It turns out that the TPU is even faster on the LSTM model (21402 examples/s): ~12.9 times faster than a P100 (1658 examples/s) and ~7.7 times faster than a V100 (2778 examples/s)!

不過這邊就沒特別提到精度了...

AWS 大阪區

在寫前一篇「Inter-Region VPC Peering 的範圍大幅增加」時,跑去查了資料「AWS Regions and Endpoints」,發現 AWS 增加了 ap-northeast-3,但不同於其他區域的標法,大阪區的 Region Name 是「Asia Pacific (Osaka-Local)」,那個 Local 不知道代表什麼 XD

另外透過搜尋翻到的,在 Twitter 上的 AWS 日本帳號也提到了大阪區的消息:

Archives