Backblaze 開了歐洲區機房

Backblaze 開了歐洲機房,所以包括了一般性的 Computer BackupB2 Cloud Storage 都可以選擇要放哪邊了...

歐洲的點是放在荷蘭:

Big news: Our first European data center, in Amsterdam, is open and accepting customer data!

價錢也都跟美國的相同:

Whether you choose EU Central or US West, your pricing for our products will be unchanged:

對於在意資料放美國機房的問題應該有緩解一些...

行李箱搭乘新幹線的限制

東海道・山陽新幹線與九州新幹線在明年五月要導入大型行李管制機制:「新幹線へ持ち込みの大型荷物 予約制に」,官方的新聞稿在「東海道・山陽・九州新幹線特大荷物置場の設置と事前予約制の導入について」這邊。

限制的對象是長寬高三邊加起來超過 160cm,且在 250cm 以內的行李,會安排在空間讓你可以放置。事前預約不用錢,臨時則需要 1000 日幣:

JR東海などによりますと、事前の予約が必要になるのは東海道・山陽新幹線と九州新幹線で、荷物は車両の後部にあるスペースやデッキに設けられる予定の鍵付きの専用のコーナーに置きます。

対象となるのは、大型のスーツケースなど3辺の合計が160センチを超えて250センチまでの荷物で、窓口やインターネットなどで、事前に指定席とセットで予約する必要があります。

事前に予約をして荷物を持ち込んだ場合は無料ですが、予約をしていない場合には、有料となり、1000円を支払わなければなりません。

看了一下我自己有在用的 27 吋戰車規格,還在範圍內:

(外部) 高65cm(不含輪高) 寬45cm 厚29cm 重量5.2 kg
ABS 塑料

翻了「尺吋│28吋以上 - PChome 24h購物」這頁看了一下,29 吋有些有超過,有些沒超過,對於之後要去日本拉行李的人 (常發生在買 JR Pass,或是不同點進出的人) 應該要注意一下了...

目前公佈的是這兩個區段:

引用自己論文的問題...

Nature 上點出來期刊論文裡自我引用的問題 (這邊的自我引用包括了合作過的人):「Hundreds of extreme self-citing scientists revealed in new database」。

開頭舉了一個極端的例子,Vaidyanathan 的自我引用比率高達 94%,而學界的中位數是 12.7%,感覺是有某種制度造成的行為?

Vaidyanathan, a computer scientist at the Vel Tech R&D Institute of Technology, a privately run institute, is an extreme example: he has received 94% of his citations from himself or his co-authors up to 2017, according to a study in PLoS Biology this month. He is not alone. The data set, which lists around 100,000 researchers, shows that at least 250 scientists have amassed more than 50% of their citations from themselves or their co-authors, while the median self-citation rate is 12.7%.

會想要提是因為想到當年 Google 的經典演算法 PageRank,就是在處理這個問題... 把 paper 換成 webpage 而已。

AWS System Manager 支援 SSH 的 -L 功能 (Port Forwarding)

AWS System Manager 宣佈支援了 SSH Port Forwarding 的功能 (也就是 OpenSSH 指令裡的 -L):「New – Port Forwarding Using AWS System Manager Sessions Manager」。

以往是連到那台主機上後,再透過 -R 反過來再穿一層,但這必須在那台機器有 Internet 存取權限的情況下才有辦法做... 這次的方法是 AWS System Manager 直接提供了,所以只需要可以連到主機就可以做。

Amazon Route 53 增加了即時的 Query 數量資訊

AWSRoute 53 增加了 Query 數量的資訊 (加到 CloudWatch 內):「Amazon Route 53 Now Publishes Query Volume Metrics for Public Hosted Zones」。

下午的時候連進去看沒看到,回家後想起來 Route 53 是全球性服務,切到 us-east-1 上就看到了...

算是很基本的功能,這樣可以很方便的看一下使用情況,然後就可以透過這些資料調整 TTL,有些為了要快速切換的可以設短一點,有些不太變動但 query 量很大的則是要設長一點...

IBM 把 OpenPOWER Foundation 交給 The Linux Foundation

標題雖然是「Big Blue Open Sources Power Chip Instruction Set」,但實質上應該就是 IBMOpenPOWER Foundation 交給 The Linux Foundation

找了一下兩邊的新聞稿,其中 The Linux Foundation 的新聞稿在「The Linux Foundation Announces New Open Hardware Technologies and Collaboration」這邊,但 OpenPOWER 的網站好像從 2018 年年底就沒更新了...

開放硬體最近比較紅的應該是 RISC-VOpenRISC 這些專案?IBM 這一招不知道是怎麼樣...

Facebook 修正錯字的新演算法

先前 Facebook 已經先發表過 fastText 了,在這個月的月初又發表了另外一個演算法 Misspelling Oblivious Embeddings (MOE),是搭著本來的 fastText 而得到的改善:「A new model for word embeddings that are resilient to misspellings」。

Facebook 的說明提到在 user-generated text 的內容上,MOE 的效果比 fastText 好:

We checked the effectiveness of this approach considering different intrinsic and extrinsic tasks, and found that MOE outperforms fastText for user-generated text.

論文發表在 arXiv 上:「Misspelling Oblivious Word Embeddings」。

依照介紹,fastText 的重點在於 semantic loss,而 MOE 則多了 spell correction loss:

The loss function of fastText aims to more closely embed words that occur in the same context. We call this semantic loss. In addition to the semantic loss, MOE also considers an additional supervisedloss that we call spell correction loss. The spell correction loss aims to embed misspellings close to their correct versions by minimizing the weighted sum of semantic loss and spell correction loss.

不過目前 GitHub 上的 facebookresearch/moe 只有放 dataset,沒有 open source 出來讓人直接用,可能得自己刻...

Trac 1.4

剛剛看到 Trac 出了 1.4 的消息,雖然還是在用 Python 2:「Release Notes for Trac 1.4 Jinja Release」。

其中一個比較大的改變是 template engine 換掉了,從 Edgewall 自家的 Genshi 換到 Jinja2 上,目前看起來兩者都可以用,但可以預期現有的 template 要找時間換過去:「5 times speed-up when rendering query results, thanks to the migration from Genshi to Jinja2.」。

其他的改變應該還好,找個週末來把自己的 Trac 備份起來測試好了...

重新了解 Amazon EC2 的 T2/T3 Unlimited

剛好跟同事聊到 Amazon EC2 的 T2/T3 Unlimited,因為有些疑惑所以回家查了一下資料,發現以前的理解不夠完整。這是 T2/T3 Unlimited 的說明文件:「Unlimited Mode for Burstable Performance Instances」。

在文件的這塊說明了 T2/T3 Unlimited 模式的計算方式:

When its CPU utilization falls below the baseline, it uses the CPU credits that it earns to pay down the surplus credits that it spent earlier. The ability to earn CPU credits to pay down surplus credits enables Amazon EC2 to average the CPU utilization of an instance over a 24-hour period. If the average CPU usage over a 24-hour period exceeds the baseline, the instance is billed for the additional usage at a flat additional rate per vCPU-hour.

我本來以為是剩下的 CPU credit 不夠時就會被收費,但依照官方文件的說明,是可以用後面賺到的 CPU credit 支付前面使用的 CPU credit,而可跨越的時間區間是 24 小時。

所以有時候會在 AWS web console 上看到 CPU 沒有在用,但是 CPU credit 卻長回不來的情況,是因為這時候還在還之前的債...