1990 年代俄羅斯人用 VHS 帶 (錄影帶) 備份數位資料的方法:ArVid

Hacker News 上看到「ArVid: how Russians squeezed 4 hard drives into one VHS tape in the 90s」這篇,在 1990 年代俄羅斯人發明了用 VHS 帶 (錄影帶) 備份數位資料的方式,這個套件叫做 ArVid

方法是利用家裡已經有的 VHS 機 (錄影機),然後在 386 的電腦上接一張 ISA 介面的卡 (對比現在的電腦環境就是 PCI-e 介面卡),然後把 ISA 卡接到 VHS 機的 Video In (負責備份資料) 與 Video Out (負責取回資料),另外 ISA 卡還有一個紅外線 LED 發射的模組線可以接到 (貼到) VHS 機器的接收處,這樣可以讓 ISA 卡透過「遙控器」的協定控制 VHS 播放器。

這個點子用的媒介其實類似於磁帶機,只是 ArVid 為了使用現成的 VHS 機,多了一個轉換成影像的步驟。

這邊 ArVid 加上了 Hamming code,提供之後讀取時,發現錯誤以及修正的能力。

三個小時的 VHS 帶可以存 2GB 的資料,這個空間大小的感覺拉一下「History of hard disk drives」這頁的資訊,可以感覺一下 1990 年代前期時這樣的東西大概是什麼感覺:

1990 – IBM 0681 "Redwing" – 857 megabytes, twelve 5.25-inch disks. First HDD with PRML Technology (Digital Read Channel with 'partial-response maximum-likelihood' algorithm).

1991 – Areal Technology MD-2060 – 60 megabytes, one 2.5-inch disk platter. First commercial hard drive with platters made from glass.

1991 – IBM 0663 "Corsair" – 1,004 megabytes, eight 3.5-inch disks; first HDD using magnetoresistive heads

1991 – Intégral Peripherals 1820 "Mustang" – 21.4 megabytes, one 1.8-inch disk, first 1.8-inch HDD

1992 – HP Kittyhawk – 20 MB, first 1.3-inch hard-disk drive

是個很有趣的產品啊...

Netflix 放出了 2023 上半年一萬八千部的播放統計資料

在「What We Watched: A Netflix engagement report (netflix.com)」這邊看到的,Netflix 的文章在「What We Watched: A Netflix Engagement Report」這邊,標題提到的 Excel 報告在 What_We_Watched_A_Netflix_Engagement_Report_2023Jan-Jun.xlsx 這邊。

Hacker News 上的留言 id=38621625 有提到這是 Writers Guild of America 的聯合罷工 (參考英文維基百科的「2023 Writers Guild of America strike」或是中文維基百科「2023年美國編劇協會大罷工」) 所協商出來的成果:

This is an outcome of the WGA strike negotiations. Now writers (and actors, and anyone else) can use this information to better negotiate their worth with studios, rather than it being 1-sided. All other streaming services should be following suit soon.

在「What We Won」這邊可以看到關於 transparency 的部分:

Streaming data transparency: Companies agree to provide the Guild, subject to a confidentiality agreement, the total number of hours streamed, both domestically and internationally, of self-produced high budget streaming programs (e.g., a Netflix original series). Aggregated information can be shared.

打開 Excel 檔可以看到 Netflix 就放出最低限度的資料,但就如同 comment 提到的,這份資料以及足以讓很多人有機會反過來談更好的合約。

另外一方面,也可以預期這份公開資料交叉其他的 metadata 可以分析出一些有趣的東西?

X (Twitter) 的工程團隊列出了最近做的事情

Hacker News 上看到的討論,在 Elon Musk 接手後的 X (Twitter),工程團隊做了什麼事情:「X Engineering Year Retrospective (twitter.com/xeng)」,原推在:

其中裡面有些蠻有趣的,出現了一些平常不太會出現的數字資訊。

我比較有興趣的關掉了加州 Sacramento DC 的這個部分,而光是這個 DC 就有 148k 台 server (是 server,不是 VM 或是 container),而且也提到電力少了 48MW,看起來是把這些 server 廢掉,而不是轉到其他機房?

- Shutdown the Sacramento data center and re-provisioned the 5,200 racks and 148,000 servers, which generated more than $100M in annual savings. In total, we freed up 48 MW of capacity and tore down 60k lbs. of network ladder rack before re-provisioning it to other data centers.

話說一個 Twitter 機房用 48MW... 查了一下台電網站,核三的一個機組的供電量也才 951MW:

而且 Twitter 服務要用到 148k server,hmmm...

日本 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 先記起來,以後也許在其他場景有機會用到?

KeyDB:使用 Multithreading 改善 Redis 的效能

Hacker News 上看到有支援 Multithreading 的 Redis fork:「KeyDB – A Multithreaded Fork of Redis (keydb.dev)」,官網在「KeyDB - The Faster Redis Alternative」這邊。

不過這篇是要記錄從 Hacker News 看到的雷點,這樣以後自己再找資料的時候會比較容找到。

36022425 這篇是跳下去用發現不太行,最後在 application 端實作需要的 feature,後端還是用原廠的 Redis:

To counter what the other active business said, we tried using KeyDB for about 6 months and every fear you concern you stated came true. Numerous outages, obscure bugs, etc. Its not that the devs aren’t good, its just a complex problem and they went wide with a variety of enhancements. We changed client architecture to work better with tradition Redis. Combined with with recent Redis updates, its rock solid and back to being an after-thought rather than a pain point. Its only worth the high price if it solves problems without creating worse ones. I wish those guys luck but I wont try it again anytime soon.

* its been around 2 years since our last use as a paying customer. YMMV.

另外是在專案裡搜尋「is:open is:issue label:"Priority 1"」的結果可以看到不太妙,在 36021108 這邊有提到的問題:

Filed July, eventually marked priority 1 in early December, not a single comment or signs of fix on it since. That doesn't look good at all.

然後 36020184 有提到 Snap 買進去後沒有什麼在管 open source project 的部分了:

I think I'll stay far away from this thing anyway. Numerous show-stopper bug reports open and there hasn't been a substantial commit on the main branch in at least a few weeks, and possibly months. I'll be surprised if Snap is actually paying anybody to work on this.

Brave 宣佈 Brave Search 完全使用自己的資料,不用 Bing 的了

Brave 宣佈 Brave Search 獨立,不再使用 Bing 的資料了:「Brave Search removes last remnant of Bing from search results page, achieving 100% independence and providing real alternative to Big Tech search」。

依照 Brave 的說明,先前大約 7% 是來自 Bing 的 API:

Every Web search result seen in Brave Search is now served by our own index. We’ve removed all search API calls to Bing, which previously represented about 7% of query results.

但只要商業模式還是廣告,我應該不會去用... 但比起目前市場上一堆包其他家 search engine 的搜尋引擎來說,這的確是個好消息。

用 Automerge 處理 CRDT 問題

上個月看到 Automerge 出了 2.0 版的消息:「Automerge 2.0」,Automerge 這個套件可以幫你處理複雜的 CRDT 結構 (Conflict-free replicated data type)。

可以看到 Automerge 在 2.0 之後的效能改善不少,可以跟 yjs 比較了:

所以練了一下手測界面怎麼用,另外也看一下 conflict 時的處理方式。

這邊先產生 hello, world.,然後做了三個操作,第一個是把開頭的 h 改成 H;第二個是把 world 改成 test;第三個是把 world 改成 example

(() => {
  const Automerge = require('@automerge/automerge');

  let doc1 = Automerge.init();

  doc1 = Automerge.change(doc1, 'Init', doc => {
    doc.text = new Automerge.Text();
    doc.text.insertAt(0, 'h', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd', '.');
  });
  
  let doc2 = Automerge.clone(doc1);
  let doc3 = Automerge.clone(doc1);

  doc1 = Automerge.change(doc1, 'Capitalize', doc => {
    doc.text.deleteAt(0);
    doc.text.insertAt(0, 'H');
  });
  doc2 = Automerge.change(doc2, 'world => test', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'test');
  });
  doc3 = Automerge.change(doc3, 'world => example', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'example');
  });

  let finalDoc = Automerge.merge(doc1, doc2);
  finalDoc = Automerge.merge(finalDoc, doc3);
  console.log(finalDoc);
})();

這樣最後會產生出 Hello, testexample.

{
  text: Text {
    elems: [
      'H', 'e', 'l', 'l', 'o',
      ',', ' ', 't', 'e', 's',
      't', 'e', 'x', 'a', 'm',
      'p', 'l', 'e', '.'
    ]
  }
}

這結果看起來還行。

只能說以前要是有這些 library 就好了,當初在 KKBOX 做雲端歌單自己搞半天...

拿 JupyterLab 生一些圖

先前看到「Python Data Visualisation」這篇就在研究要怎麼在 Linux 桌面環境下用 Python 搭配 Altair 生圖,在寫一些文件的時候會方便一些。

但先前一直卡住 (不是生不出來,而是流程不順),所以就放在 browser tab 上面一直沒動。直到前幾天看到 JupyterLab Desktop 改版,想說來看看改得如何:「Introducing the new JupyterLab Desktop!」。

先講一下結論,安裝不算太困難,界面也不差 (畢竟是重點),但 interface bug 很多,常常按下去沒反應 XD

第一次跑的時候我先把 Python 的環境指到 pyenv~/.shim/python3

先拿文章裡的範例丟進去跑:

import altair as alt
from vega_datasets import data

source = data.stocks()

alt.Chart(source).mark_line().encode(
    x='date',
    y='price',
    color='symbol',
    strokeDash='symbol',
)

會長這樣:

然後輸出圖表的右邊的 menu icon 展開後可以選 Save as PNG 存成圖片。

雖然不能直接存到 clipboard 方便我直接貼到 Imgur,但至少可以先打磨出想要的圖,再輸出成檔案處理...

Vultr 開大阪機房

Vultr 宣布開大阪機房:「New Cloud Data Center Location: Osaka, Japan」。

本來的東京機房從 HiNet 過去會塞,可以看到每天都會有一段時間 latency 會飄起來:

從 HiNet 過去 Vultr 東京機房是走 PCCW 的線路:

從 Vultr 東京機房回來是走 NTT 的線路:

如果是 Vultr 大阪機房的話,先用 mtr 看了一下 latency,狀況似乎是好很多?好像可以考慮把東京的機器搬到大阪看看...