Tag: apache

Sentry 的 License 不是 Open Source License...

前一篇「Sentry 的替代品：GlitchTip」我自己提到：

Sentry 本身已經是 open source software 了

結果在 HN 上面馬上就看到討論：「Sentry: From the Beginning (cra.mr)」，其中 id=38097463 這邊提到：

The article doesn't appear to mention that Sentry abandoned open source.

在 LICENSE 這個檔案的記錄 History for LICENSE 裡慢慢翻，可以翻到 Apache License, Version 2.0 是在 2589cbef43659151e70fd3d20eb8b34d7f1f574f (2019/06/11) 這邊加進去的，而變成 BSL 是在 e2b7c743af70e192588d843512412e653eddab17 (2019/11/07) 這邊發生的，另外也有對應的 blog 文章：「Re-Licensing Sentry」。

ClickHouse 弄了一個 C++ 寫的 ZooKeeper drop-in replacement：ClickHouse Keeper

在 Hacker News 上看到「ClickHouse Keeper: A ZooKeeper alternative written in C++ (clickhouse.com)」，原文是「ClickHouse Keeper: A ZooKeeper alternative written in C++」。

在 distributed coordination 這個領域目前應該是 etcd 比較知名，但 Apache ZooKeeper 畢竟算是元老，還是有不少應用程式會把 ZooKeeper 當作基礎建設在用。

因此 etcd 也包了一個 zetcd，可以用 etcd 當作底層結構，但提供 ZooKeeper API 的介面讓應用程式使用：

Serve the Apache Zookeeper API but back it with an etcd cluster

這次 ClickHouse 的人搞出一個用 C++ 寫的 ClickHouse Keeper，定位是 drop-in replacement，想要解決現有的應用程式遇到的記憶體資源問題。

從開頭的說明就可以看到著重在這塊：

up to 46 times less memory than ZooKeeper ​​for the same volume of data while maintaining performance close to ZooKeeper.

而對於新的應用程式，在開發時應該就不太會選 ZooKeeper 了，畢竟連 distributed lock 都得自己操作 znode 把功能疊出來 (像是官網很貼心的還提供了「ZooKeeper Recipes and Solutions」，裡面提供了 lock 的方法)，而這種事情太累，用 etcd 方便太多...

日本 LINE 推出的 LLM (以日語材料訓練)

看到「36億パラメータの日本語言語モデルを公開しました」這篇，日本的 LINE 丟出 Apache License 2.0 的 LLM，拿起來跑看看還蠻有趣的：

他的特點是用日語資料訓練出來的 LLM：

最終的な学習には約650GBのコーパスを利用していますが、英語の大規模コーパスとして一般的に用いられているもの（Pileコーパス）が約800GBであることを踏まえると、我々のデータも遜色ない大きさであると言えます。

我拿 1.7B 跑，小修改一下故意給英文的 prompt 後，可以看到輸出頗有趣的，畢竟是從日文資料訓練出來的：

{'generated_text': 'An apple a day keeps the doctor away.\n「一日リンゴ1個」は apple days で'}
{'generated_text': 'An apple a day keeps the doctor away thinking happier. The biggest happ'}
{'generated_text': 'An apple a day keeps the doctor away from here.」と英語で訳しましょう。「I have a dream'}
{'generated_text': 'An apple a day keeps the doctor away(sometimes usually thinks far a'}
{'generated_text': 'An apple a day keeps the doctor away. 日はまたのぼり、 医者は去って行った。 They'}
{'generated_text': 'An apple a day keeps the doctor away thought about being in the center of the'}
{'generated_text': 'An apple a day keeps the doctor away from all the time.\n16. I feel like'}
{'generated_text': 'An apple a day keeps the doctor away and draws and eats around one table'}
{'generated_text': 'An apple a day keeps the doctor away from your mother\nAnd another male you are'}
{'generated_text': "An apple a day keeps the doctor away. What's the opinion you wrote in"}

這邊有訓練的運算量計算，1.7B 的 model 訓練換成起來會用道 4000 小時的 A100 80GB (假設你有 100 張的話，就是 40 小時)：

本モデルの構築に要した時間について、例えば1.7BモデルについてはA100 80GBで換算し、約4000GPU時間を費やしています。学習時間は特に日本語の大規模言語モデルの学習では公開されていないことが多く、適切な比較はできませんが、例えば rinna 0.3Bモデルの学習はV100 32GBで約8600GPU時間を費やしているようで、費やした時間に比して効率の良い学習が行えていると考えられます。

目前是提到有計畫要放出 instruction tuning 的版本：

また、これらのモデルについて、指示文に対して適切な出力を行えるようにチューニング（Instruction tuning）したモデルを近日中に公開予定です。続報は@LINE_DEVをフォローしてお待ち下さい。

這個 LLM 先記起來，以後也許在其他場景有機會用到？

Apache License 2.0 的 RedPajama 7B 釋出

在 LLaMA 出來以後，打造 open source license 的 LLM 變成大家期待的事情，而 RedPajama 算是蠻多人看好的項目。

結果還在算的過程中間，路上殺出來 Falcon LLM，在釋出當下以一個比較寬鬆的 license (但還不是 open source license)，到了六月初直接宣布改用 Apache License, Version 2.0，而且同時放出 7B 與 40B 兩個 model，讓 RedPajama 的消息瞬間被壓下去...

現在 RedPajama 放出 7B 了，而且也宣稱在 HELM 上比 Falcon 7B 好：「RedPajama 7B now available, instruct model outperforms all open 7B models on HELM benchmarks」，在 Hacker News 上對應的討論串在「RedPajama 7B (an Apache 2.0-licensed LLaMa) is now available (together.xyz)」這邊。

不過從這幾個月社群討論的感覺，可以看到大家都覺得 7B 太小了，目前大家都希望是 3090/4090 等級可以跑的顯示卡在當標準，差不多會是 LLaMA 13B 或是 30B (4-bit) 的 model。

這幾個月的競爭太激烈，放話完還沒 release 就被幹掉...

Apple 使用 Cassandra 的量

Hacker News Daily 上看到的：「Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB (twitter.com/erickramirezau)。原文在 Twitter 上：

有些數字有點對不太起來，裡面提到 300K nodes + millions of QPS，但通常讀寫都算 QPS，這樣聽起來很少？所以有種可能這邊是只有算 read 的部份...

另外照片裡面提到 Over two petabytes per cluster，但有 thousands of clusters，最後卻只有 Hundreds of petabytes of data，完全對不上，就算當作平均值來算也對不上，只能猜測是最大的 cluster 而不是 per cluster。

裡面矛盾的地方太多，所以這些數字基本上沒有參考價值，現在能讀出來的只知道 Apple 有在用 Cassandra，然後不是少少幾台 PoC 等級的使用。

Google 提供掃描 JAR 檔內是否有中獎的 Log4j 的工具

在 Hacker News 首頁上看到 Google 提供了一套用 Golang 寫的工具，可以掃描 JAR 檔裡面是否有中獎的 Log4j：「log4jscanner」，對應的討論在「Log4jscanner (github.com/google)」這邊。

看起來是內部工具，放出來前先把 vcs history 清掉了：

We unfortunately had to squash the history when open sourcing. The following contributors were instrumental in this project's development: [...]

另外討論裡也有人提到「OWASP Dependency-Check」這個工具也可以掃，這套就更一般性了：

Dependency-check automatically updates itself using the NVD Data Feeds hosted by NIST.

受到 Log4j2 影響的清單

最近大家都在忙著補 Log4j2 的安全漏洞 (先前在「Log4j2 的 RCE」這邊有提到)，有人整理了目前受到影響的軟體的清單以及對應的討論連結：「Log4Shell log4j vulnerability (CVE-2021-44228) - cheat-sheet reference guide」。

用這包來翻起來會方便一些，另外也可以順便翻一下有什麼其他軟體中獎...

然後 Cloudflare 的 CEO Matthew Prince 在 Twitter 上有提到從他們家的資料看起來，2021/12/01 就已經有攻擊在外面跑了，這也是之前會說這是 0-day 的原因：

Log4j2 的 RCE

昨天爆出來 Log4j2 的 RCE，看了一下 pattern，只要是 Java stack 應該都很容易中獎：「Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package」，Hacker News 上對應的討論在「Log4j RCE Found (lunasec.io)」這邊可以看。

LunaSec 宣稱這是 0-day RCE，不過 Log4j2 的修正版本 2.15.0 在 2021/12/06 出了，而 exploit 被丟出來是 2021/12/09，但不確定在這之前是不是已經有 exploit 在 internet 上飛來飛去了...

丟出來的 exploit sample (CVE-2021-44228-Apache-Log4j-Rce) 是用 LDAP 來打，雖然大多數的 Java 版本不受影響，但還是有其他的面可以攻擊，所以整體上還是很容易打穿，該升級的還是得趕快升級：

Updates (3 hours after posting): According to this blog post (see translation), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. An attacker could still leverage existing code on the server to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

週末苦命時間...

LLVM 的更換授權進展

在 Hacker News Daily 上看到「LLVM relicensing update & call for help」這篇，在講 LLVM 計畫從 UIUC license 與 MIT license 授權轉成 Apache License 2.0 的進展，在 Hacker News 上的討論「LLVM relicensing update and call for help (llvm.org)」也可以翻一下。

目前的規劃是這樣：

文章開頭還是先花了一些篇幅解釋，這個計畫主要是要處理專利的問題，原先的 developer policy 對於專利的句子太粗糙，會授權過多的權力給 LLVM。這對於一般個人可能影響不大，但對於手上有一卡車專利的公司來說就不太願意了。

另外一個問題是 LLVM 遇到的問題，因為 runtime library 的部份是用 UIUC license + MIT license 授權，但主體是用 UIUC license 授權，這使得主體的程式碼不能隨意搬到 runtime library 裡面：

The run time libraries were dual licensed under the UIUC and MIT license; the rest of the code only under the UIUC license. Therefore, we could not easily move code to run time libraries from other parts. The reason run time libraries were dual licensed was to enable linking to run time library binaries without requiring attribution to LLVM.

因為這些目標，所以新的授權會是 Apache License 2.0 為主，裡面有設計還算合理的專利授權條件，另外大家也算熟悉，再來是針對 object code 以及 GPLv2 設計了例外條款：

As an exception, if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License.

In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 ("Combined Software") and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.

在「Long tail of individuals and corporations without a relicensing agreement yet」這邊有目前還沒有同意重新授權的人以及團隊的資料，看起來不會是每個人都願意重新授權，到時候可能還得再挑出來重寫，但有些可以獨立出來的可能可以維持，畢竟 UIUC licesne 與 MIT license 都是 permissive license，只要放到另外一個目錄下，大家知道不是 Apache License 2.0 就還好...

OpenSSL 3.0 釋出，使用 Apache License 2.0

OpenSSL 3.0 推出了，這是轉換到 Apache License 2.0 後的第一個正式版本：「OpenSSL 3.0 Has Been Released!」。

中間跳過 2.0 的原因在維基百科上也有提到，因為之前被 OpenSSL FIPS module 用掉了：

The major version 2.0.0 was skipped due to its previous use in the OpenSSL FIPS module.

雖然 3.0.0 看起來是大版本，不過主要的功能都在 OpenSSL 1.1.1 先加進去了，沒有什麼特別的理由現在就要升級到 3.0.0...