jQuery UI 與 jQuery Mobile 進入維護模式

OpenJS Foundation (先前的 jQuery Foundation) 宣佈 jQuery UIjQuery Mobile 進入維護模式:「jQuery maintainers update and transition jQuery UI as part of overall modernization efforts」、「jQuery maintainers continue modernization initiative with deprecation of jQuery Mobile」。

jQuery UI is in maintenance-only mode. Users should not expect any new releases, though patches may be issued to resolve critical security, interoperability, or regression bugs.

The team announced that the cross-platform jQuery Mobile project under its umbrella is fully deprecated as of October 7, 2021.

應該就是沒有足夠的動能繼續開發了,維持個窗口在有 security issue 時處理...

各種反直覺的項目

前陣子看到「The most counterintuitive facts in all of mathematics, computer science, and physics」這篇,講各種反直覺的項目,有空的時候拉一兩個來讀還蠻有趣的...

第一個提到的是 Homomorphic encryption。在密碼學的保護概念中,密文是不能被操作的,但我們可以透過重新設計密碼學系統,讓密文可以被運算:

1. It is possible to compute over encrypted data without access to the secret key: https://en.wikipedia.org/wiki/Homomorphic_encryption

2009 年的時候第一個 FHE (fully homomorphic encryption) 演算法被提出來後就被大量討論,這代表你可以把資料加密後丟上雲端,利用雲端的大量運算資源運算完後,再把資料拉回地端解密,得到運算後的結果。這算是 Lattice-based cryptography 的一個很重大的應用。

其他的主題也蠻有趣的,先丟著找機會翻...

Wasabi 與 Storj DCS

WasabiStorj 是在看到「Will Cloudflare R2 Win Customers from Amazon S3?」這篇文章時翻到了三個 Cloud Storage Provider,文章本身我倒是沒什麼吸收...。

第一個是 BackblazeB2,這個產品平常的曝光度就還算夠。

另外是 Wasabi 的部份,其中一個賣點是免費的頻寬,但其實限制意外的多。首先是各地區的價錢:

我找了一下到底是什麼地區,目前只有看到「Wasabi Technologies Inc Status」這邊有編號 (US-East-1、US-East-2、US-Central-1、US-West-1、EU-Central-1、AP-Northeast-1),但也沒找到地區... US 的都在美國沒問題,AP-Northeast-1 應該是日本,但 EU-Central-1 是哪裡就找不到了。

另外是 pay-as-you-go 的方案最小是 1TB,如果是歐美區的話是 US$5.99:

For customers using the Wasabi pay-as-you-go pricing model, Wasabi has a minimum monthly charge associated with 1 TB of active storage. If you store less than 1 TB of active storage in your account, you will still be charged for 1 TB of storage based on the pricing associated with the storage region you are using.

然後也有 90 天的最短計價時間:

Wasabi has a minimum storage duration policy that means if stored objects are deleted before they have been stored with Wasabi for a certain number of days (90 days when using the Wasabi pay-go pricing model), a Timed Deleted Storage charge equal to the storage charge for the remaining days will apply.

另外 Wasabi's free egress policy 這邊也可以看出來他們的設計就是拿來當 storage 用,然後前面需要擋 CDN 之類的服務。

最後一個是 Storj 的 DCS,US$4/TB/month 的空間費用,與 US$7/TB 的流量費用感覺還算便宜?他的做法是把檔案拆成 80 份,然後取 29 份就可以算回來:

How many Nodes are files stored on?

80. We split each file into 80 different encrypted pieces, and each piece is stored on a different Node.

When you retrieve an object, only 29 of its 80 pieces are needed to reconstitute that object. With no central point of failure, your data is always quickly available, all over the world.

這部份是則是透過 Reed-Solomon error correction 實做:

Automate file repair and know that Reed-Solomon erasure coding enables the highest levels of durability for all files uploaded to Storj DCS.

好一陣子沒看到 Reed-Solomon 了,沒想到在這邊看到... 先不管技術的部份,看起來 Storj DCS 的價錢可以玩看看。

PyPy JIT 的改善

PyPy 這邊看到 JIT 的重大進展:「Better JIT Support for Auto-Generated Python Code」。

他們在 Tornado 上重製出來效能問題,後面也都是用這個例子在測試:

If you render a big HTML template (example) using the Tornado templating engine, the template rendering is really not any faster than CPython.

看起來上的 workaround 是在撞到 trace limit 時標記起來,之後再遇到時就可以跳進 special mode,接著處理下去避免浪費掉之前處理過的 trace:

After we have hit the trace limit and no inlining has happened so far, we mark the outermost function as a source of huge traces. The next time we trace such a function, we do so in a special mode. In that mode, hitting the trace limit behaves differently: Instead of stopping the tracer and throwing away the trace produced so far, we will use the unfinished trace to produce machine code.

效能可以看到改善很多:

看起來這個概念有打算在 3.8 的時候放進去:

The work described in this post tiny bit experimental still, but we will release it as part of the upcoming 3.8 beta release, to get some more experience with it. Please grab a 3.8 release candidate, try it out and let us know your observations, good and bad!

Django 的 template engine 不怎麼快,用 Jinja2 可能是一個方法,但既有的 project 如果有遇到 template engine 的效能問題,也許也可以翻看看 PyPy 解得如何...

Ubuntu 下的滑鼠滾輪速度

這陣子因為經常切回 WindowsD2R,發現 Windows 下的滾輪速度快多了,回到 Ubuntu 20.04 下發現無法調整滑鼠滾輪的速度,找了一些方案測試,發現居然地雷還是超多 XD

搜尋可以找到「Increase mouse wheel scroll speed」與「How to change my mouse wheel scroll rate?」這兩篇,被推最多的都是 imwheel,但這套軟體的最新版是 2004 年,實際上用就會發現配合現代的系統 bug 很多...

另外用的方案是「Mouse scroll wheel acceleration, implemented in user space」,作者用 Python 去控制加速,測了一下正常多了。範例給的 ./main.py -v --exp 1 其中的 --exp 1 實際用起來有點太快,我改成 0.75 比較習慣。

先照著作者提到的,把 dependency 都裝起來,接下來掛到 Session and Startup 裡面,在登入後跑起來就可以了:

Vultr 可以帶自己的 IP 位置使用

Twitter 上看到 Vultr 可以帶自己的 IP 使用:

翻了一下發現是 2015 年就提供的功能:「Announce IP Space on the Cloud with Vultr」,而旁邊的 LinodeDigitalOcean 似乎都沒翻到...

在文件「Configuring BGP on Vultr」這邊可以看到需要先驗證 IP 是你的,算是業界常見的作法,跟當初申請 AWSDirect Connect 類似的作法。

Amazon SES 總算支援 2048 bits RSA key 了

Amazon SES 總算是支援 2048 bits RSA key 了:「Amazon SES now supports 2048-bit DKIM keys」。

然後講一些幹話... 隔壁微軟早在 2019 年就支援 2048 bits RSA key 了:

Until now, Amazon SES supported a DKIM key length of 1024-bit, which is the current industry standard.

另外用 ECC 演算法的一直都沒進 standard,像是已經先 book 了 RFC 8463 位置的 Ed25519,在 draft 狀態放好久了:「A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)」,還有用 ECDSA 的「Defining Elliptic Curve Cryptography Algorithms for use with DKIM」也是放著,不知道是卡到什麼東西,可能是專利?

Cloudflare R2 Storage 的插曲...

Hacker News 首頁上看到「Cloudflare's Disruption (stratechery.com)」這篇,文章「Cloudflare’s Disruption」這篇其實還好,主要就是分析一下 Cloudflare R2 Storage 在下的棋,真的讓我想寫的是反而是 Hacker News 上的討論...

首先是提到了 S3 -> R2 -> Q1 -> P0 這個:

ksec 36 minutes ago | unvote [–]

^gt; The service will be called R2 — “one less than S3,” quipped Cloudflare CEO Matthew Prince in an interview with Protocol ahead of Cloudflare’s announcement

Oh I never thought of that. So the next one is Q1 and final one would be P0.

另外下面有也提到 IBMHAL

piaste 33 minutes ago | unvote [–]

And it is likely inspired by the old joke that 2001: A Space Odyssey's HAL was one less than "IBM".

下一個 Q1 是明年了,來看看 2022Q1 會不會有 P0 issue XDDD

GitHub 的 MySQL 架構與數字

前幾天 GitHub 有寫一篇文章提到他們的 MySQL 是怎麼 scale 的,另外裡面也有一些數字可以看:「Partitioning GitHub’s relational databases to handle scale」。

他們最主要的 database cluster 叫做 mysql1,裡面有提到 2019 年的時候這個 cluster 是 950K qps,其中 primary 有 50K qps:

In 2019, mysql1 answered 950,000 queries/s on average, 900,000 queries/s on replicas, and 50,000 queries/s on the primary.

在 2021 年的時候變成 1.125M qps,其中 75K qps 在 primary 上:

Today, in 2021, the same database tables are spread across several clusters. In two years, they saw continued growth, accelerating year-over-year. All hosts of these clusters combined answer 1,200,000 queries/s on average (1,125,000 queries/s on replicas, 75,000 queries/s on the primaries). At the same time, the average load on each host halved.

另外這幾年比較成熟的方案都拿出來用了,包括用 ProxySQL 降低連線數的壓力 (connection pool 的概念):

[W]e started using ProxySQL to reduce the number of connections opened against our primary MySQL instances.

ProxySQL is used for multiplexing client connections to MySQL primaries.

另外用 Vitess 協助 sharding 之間的轉移:

Vitess is a scaling layer on top of MySQL that helps with sharding needs. We use its vertical sharding feature to move sets of tables together in production without downtime.

這兩套應該是已經蠻成熟的了... 另外也可以發現老方法還是很好用,就算在 GitHub 這種量還是可以暴力解決很多事情。

用顏色區分程式碼裡面的括弧

Hacker News Daily 上看到 VSCode 改善了 bracket pair colorization 效率的文章,才想到我的 Vim 好像沒裝這個功能:「Bracket pair colorization 10,000x faster」。

VSCode 這邊主要是引入了新的資料結構改善了計算量,有興趣的可以看一下:

Efficient bracket pair colorization was a fun challenge. With the new data structures, we can also solve other problems related to bracket pairs more efficiently, such as general bracket matching or showing colored line scopes.

我這邊則是去找 Vim 上的套件,目前看到是「Rainbow Parentheses Improved」這個,裝起來拿 PHP 程式碼看了一下還行,這樣就不用在那邊算哪個左括弧對應到右括弧...