Google 與 AWS 都釋出往 OpenTelemetry 靠攏的消息

前幾天看到 GoogleAWS 都釋出往 OpenTelemetry 靠攏的消息:「OpenTelemetry's First Release Candidates」以及「Public Preview – AWS Distro for OpenTelemetry」。

AWS 這邊的 AWS X-Ray 看起來跟 OpenTelemetry 有點關係,找了一下果然發現之前有些計畫在跑:「AWS X-Ray SDK w/ OpenTelemetry API」,不過看起來後續應該是由「AWS Distro for OpenTelemetry」這個計畫接手了。

另外 Google 這邊看起來則是 Cloud Trace 這個產品線,本來在推的 OpenCensusOpenTracing 從網站上可以看到決定會再支援兩年,但重心會改放到 OpenTelemetry 上:

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years.

翻了一下 Azure 相關的消息,先前有一些稿子是會往 OpenTelemetry 支援,但這一波沒看到新聞稿...

用 Amazon SNS 送簡訊可以固定發送號碼了

Amazon SNS 的簡訊功能可以申請固定發送號碼了:「Amazon SNS now supports selecting the origination number when sending SMS messages」。

固定的號碼包括了短碼與長碼:「Requesting dedicated short codes for SMS messaging with Amazon SNS」、「Requesting dedicated long codes for SMS messaging with Amazon SNS」。

短碼是三到七碼,依照地區而有差異:

A short code typically contains between three and seven digits, depending on the country or region that it's based in.

要注意的是短碼的部份需要開 support case 申請,而不是直接在 web console 上操作:

Open a case with AWS Support by completing the following steps.

長碼則是有可能到 12 碼,依照不同地區的設計有所不同:

A long code (also referred to as a long virtual number, or LVN) is a standard phone number that contains up to 12 digits, depending on the country that it's based in.

不過現在長碼的部份只有美國可以用,而且有速率限制:

Support for long codes is restricted to the United States only. Sending rates for long codes are restricted to 1 message per second. This restriction is set by the telecom carriers, and isn't a limitation of Amazon SNS. If you send a large volume of messages from a long code, wireless carriers might begin to block your messages. Your applications that use Amazon SNS should limit the number of messages that they send each second.

說道 Amazon SNS 送簡訊的費用,實在不怎麼好看,量小加減用 (包在 AWS 費用裡,省人力另外跑請款的單子),量大還是要找其他家接比較划算...

Debian 資助 PeerTube 發展

看到「Debian donation for Peertube development」這則消息,Debian 決定資助 10K 歐元提供給 PeerTube 發展。

不過更大的幫助應該是 PR 上的部份,這帶出來的曝光度以及「認可」的部份比 10K 歐元重要的多。

回到 Debian 決定資助的原因,是因為 DebConf20 需要一個非封閉式平台的直播架構,而 PeerTube 看起來很適合這個情境:

This year's iteration of the Debian annual conference, DebConf20, had to be held online, and while being a resounding success, it made clear to the project our need to have a permanent live streaming infrastructure for small events held by local Debian groups. As such, Peertube, a FLOSS video hosting platform, seems to be the perfect solution for us.

前幾天在「有風聲說司法部會把 Chrome 拆出 Google」這邊有提到 YouTube 很難取代的問題,這個算是其中的一個方向,試著在解決平台壟斷的問題...

四個 HDMI 的顯示卡

Facebook 上正妹 wens 問是不是用華碩的 GT710-4H-SL-2GD5 這張顯示卡:「The Most Innovative ~$50 Graphics Card For Linux Users」,看了一下是一張蠻有趣的顯示卡,而且價位還蠻有競爭力的,拉一篇出來記錄好了...

我自己是用四螢幕,先前一直都是用 1080 Ti 在接 (2 HDMI + 2 DP),但覺得好像太吃電,後來在網路上弄了一張有四個 miniDP 輸出的 Quadro P600 顯示卡,另外又找了四條 miniDP 轉 DP 的線。

換上去後發現有時候不是那麼順,後來發現是因為常常開一堆 Twitch 反而吃了不少 GPU 資源 (在 Linux 下可以用 nvidia-smi 觀察),而且有時候還是希望跑個 KataGo 分析圍棋棋局,所以還是需要 GPU 計算能力,就換回用 1080 Ti 了...

不過這張 GT710 是四個 HDMI,用一般的 HDMI 線就可以了,相較於 P600 提供的 miniDP 需要 miniDP 轉 DP 的線,取得上應該容易不少:

另外他只需要 PCI Express 2.0 (x1) 而且是被動散熱,手上的 P600 得用到 PCI Express 3.0 (x16) 而且上面還是有一顆風扇,我猜 GT710 這張應該是更省電?不過官網上沒寫 GT710 這張的功耗,不過在「GeForce 700 series」這邊是寫 19W,而 P600 的最大功耗是 40W。

目前有看到的缺點應該是多顆 4K 解析度下時的更新頻率只有 30Hz:

* Detailed digital max. resolution:
3840×2160@60Hz for 1 monitor
3840×2160@30Hz for more than 2 monitors

對於想要有多螢幕輸出的人可以考慮看看,目前查到的價位上在新台幣 2000 上下,比 Quadro 便宜不少,畢竟定位還是不太一樣...

PayPal 也要提供加密貨幣服務

先是看到「PayPal to allow cryptocurrency buying, selling and shopping on its network」這篇,另外翻到了 PayPal 的新聞稿:「PayPal Launches New Service Enabling Users to Buy, Hold and Sell Cryptocurrency」。

幾個比較重要的地方是,這次會提供的是 BitcoinEthereumBitcoin Cash 以及 Litecoin 這四種:

To increase consumer understanding and adoption of cryptocurrency, the company is introducing the ability to buy, hold and sell select cryptocurrencies, initially featuring Bitcoin, Ethereum, Bitcoin Cash and Litecoin, directly within the PayPal digital wallet.

會先提供美國 PayPal 的使用者使用,然後再展到其他服務以及地區:

The service will be available to PayPal accountholders in the U.S. in the coming weeks. The company plans to expand the features to Venmo and select international markets in the first half of 2021.

另外這次的服務也不是自己跳進去搞,而是透過 Paxos Trust Company 建立起防火牆,所以當加密貨幣那邊出包的時候大概就會切割出來:

The service is enabled in the U.S. through a partnership with Paxos Trust Company, a regulated provider of cryptocurrency products and services.

比較像是個嘗試,只是這個主題很適合發新聞稿...

Amazon SNS 也支援 FIFO 模式了

看到 Amazon SNS 也支援 FIFO 模式了:「Introducing Amazon SNS FIFO – First-In-First-Out Pub/Sub Messaging」。

Amazon SQS 在 2016 年就已經先支援了:「Amazon SQS 支援 FIFO 了」,官方的文件可以在「Amazon SQS FIFO (First-In-First-Out) queues」這邊翻到。

在使用 FIFO mode 時與 SQS 有一樣的速度限制,每個 topic 只能到 300 TPS:

You can use SNS FIFO topics in all commercial regions. You can process up to 300 transactions per second (TPS) per FIFO topic or FIFO queue. With SNS, you pay only for what you use, you can find more information in the pricing page.

不過之前有需要保持順序的應用應該都先用 SQS workaround 了,不然就是自己搞能夠 FIFO 的 pub/sub 架構了。

有風聲說司法部會把 Chrome 拆出 Google

看到這則新聞時決定讓子彈飛了一陣子,但好像沒看到什麼新消息:「Feds may target Google’s Chrome browser for breakup」,Hacker News 上也有討論可以翻翻:「Feds may target Google's Chrome browser for breakup (politico.com)」。

GoogleChrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站」這樣的事情),會直接先把 Google Chrome 拆出來的消息不算太意外。

不過大家對反壟斷調查更有興趣的應該是 YouTube 會怎麼被處理。網路上經常會看到「如何逃離 Google」之類的文章,Google 很多服務都有其他平台可以提供,或是 open source 軟體可以使用,但每次一講到 YouTube 時大家都很頭痛,都會提到 YouTube 的難以取代性,因為目前其他平台沒有一個是堪用的...

不知道什麼時候會發動調查...

HashiCorp 推出 Boundary 與 Waypoint

HashiCorp 推出了兩個新的產品。

第一個是 Boundary,這個產品看起來還很早期,但看起來想要實做 BeyondCorp 的一些想法 (可以參考之前寫的「Google 推的 BeyondCorp」):「Announcing HashiCorp Boundary」,這在 Hacker News 上有討論串,而且 HashiCorp 的老大 Mitchell Hashimoto 也有出來回答一些問題:「HashiCorp Boundary (hashicorp.com)」。

這個產品讓他慢慢發展起來應該會是不錯的 open-source implementation,不過傳統的 castle 在小一點的場合也還算夠用...

另外一個是 Waypoint,看起來是個 CI/CD 類的產品:「Announcing HashiCorp Waypoint」,在 Hacker News 上也有討論串,而且同樣的 Mitchell Hashimoto 也有在裡面回覆一些東西:「Waypoint: Build, deploy, and release applications across any platform (hashicorp.com)」。

我自己看了一下設定的方式以及一些畫面,然後再回頭看 Hacker News 上的討論,以目前得到的資訊來看,這個產品似乎沒有很明顯解決到痛點,也許就是補產品線...

Percona 對 MongoDB 的建議

看到「5 Things DBAs Should Know Before Deploying MongoDB」這篇,裡面給了五個建議,其中第五點頗有趣:

5) Whenever Possible, Working Set < RAM

As with any database, fitting your data into RAM will allow for faster reads than from disk. MongoDB is no different. Knowing how much data MongoDB has to read in for your queries can help you determine how much RAM you should allocate to your database.

這樣的設計邏輯很奇怪啊,你不要扯其他 database 啊,你們家主力的 InnoDB 一直都沒有推薦要 Working Set < RAM 啊,反過來才是用 InnoDB 的常態吧,而且在 PostgreSQL 上也是這樣吧 XDDD

現在上面的文章真的是挑著看了... XD

Atlassian 將消滅 Server 版本

Hacker News Daily 上看到 Atlassian 打算消滅 server 版本:「Moving to a cloud future, together」。

話說回來,之前工作時用 Jira 的時候 (雲端版本),所有人都抱怨 Jira 慢到爆炸的問題不知道解了沒,當時記得每個按鍵都要 10+ 秒才會反應,不管是在台灣還是在香港都很慢,然後在公司反應了十個月也都沒什麼改善 XD

至於官方說要推 cloud 版本的理由聽聽就好,Hacker News 上有些討論反而還蠻有趣的,像是講到裡面同時在維護 Cloud 與 Server 版本時遇到的問題,看起來團隊沒有足夠的能量處理這些東西:「Atlassian moving to cloud-only, will stop selling server licenses (atlassian.com)」。

另外一個是討論裡面提到的替代方案,看起來也不算很好的替代方案啊,出現 MediaWiki 作為 Confluence 的替代品,少了 WYSIWYG 其實門檻高不少耶...

來看看這波反應會有多大 XD