在桌機上擋 Facebook 各種廣告與演算法推薦文章的 userscript

發現好像沒提過這個 userscript,由於 uBlock Origin 的條件式不足以擋 Facebook 的各種廣告機制,目前需要靠 userscript 擋:「FB - Clean my feeds」。

預設會擋掉 sponsored,像是這樣:

不過在點開左下角的 icon 後,可以看到更多選項可以擋,我是把所有列出來的都勾起來了,另外多增加一個 「Interested」(我這邊用的是英文版介面的 Facebook,看到的是 Interested 這個詞):

然後經過幾次 Facebook 反制的「改版」,作者也都蠻快就更新...

歐盟決定將挪威對 Meta 的禁令擴大到整個歐盟

挪威一開始禁止 Meta 旗下的產品 (也就包括了 FacebookInstagram) 透過蒐集使用者的行為投放廣告 (behavioural advertising):「Norway court rules against Facebook owner Meta in privacy case」。

接著是挪威跟歐盟提議一起跟上 (挪威不是歐盟成員):「Norway asks EU regulator to fine Facebook owner Meta over privacy breach」。

接著就是現在了,歐盟也決定跟上:「Facebook owner Meta faces EU ban on targeted advertising」。

這樣比起單獨一個挪威的禁令強多了,而且 Meta 被打下去了,隔壁棚的 GoogleTikTok 應該也有機會接著掃蕩?

用 Fly.io 跑 RSS-Bridge,再把現有的 twitter2facebook 與 twitter2plurk 改寫

Twitter 把我本來 read-only 的兩個應用程式停用掉了,加上這陣子的新聞,就改用其他方式來處理。

用的是先前在「用 RSS-Bridge 接服務」提到的 RSS-Bridge,可以將 Twitter 的資料轉成 JSON Feed

其中 RSS-Bridge 是 PHP 寫的,剛好就拿先前在「在 Fly.io 上面跑 PHP」這邊提到的方法丟上 Fly.io,不需要自己架主機跑了。

然後把 twitter2facebooktwitter2plurk 這兩個專案裡面本來抓 Twitter API 的程式碼改成抓 JSON Feed。

先這樣子弄,之後再看看要不要搬...

Meta (Facebook) 把 MySQL replication 丟上自製的 Raft 系統

看到「Building and deploying MySQL Raft at Meta」這篇,在講 Meta (Facebook) 把 MySQL 的 replication 架構換成自己用 Raft 的系統。

舊的系統是走 MySQL 的 semisync replication:

Previously, our replication solution used the MySQL semisynchronous (semisync) replication protocol.

其中 semisync replication 是在 MySQL 5.5 加入的功能,在至少一個遠端收到 replication log 後才傳回成功 (可以設定數量):「Semisynchronous Replication」。

Semisynchronous replication falls between asynchronous and fully synchronous replication. The source waits until at least one replica has received and logged the events (the required number of replicas is configurable), and then commits the transaction.

然後舊的系統是透過一包 Python 軟體在管理這些機器的各種 failover 操作:

The control plane operations (e.g., promotions, failover, and membership change) would be the responsibility of a set of Python daemons (henceforth called automation).

這個方法常遇到的問題是切換 primary server (以前叫做 master server) 時有可能會因為 binlog position 接不起來而失敗。

所以後來 MySQL 導入了 GTID,可以緩解這個問題,但還是有可能會發生不同的 secondary server (以前叫做 slave server) 會有不一樣的資料。

而在 Meta 改出來的架構裡面,把 replication data 直接寫到一個用 Raft 同步的系統,同步到其他的 secondary server 上面:

In MySQL Raft:

  • Primary writes to binlog via Raft, and Raft sends binlog to followers/replicas.
  • Replicas/followers receive in binlog and apply the transactions to the engine. An apply log is created during apply.
  • Binlog is the replicated log from the Raft point of view.

是個一般單位不太會遇到的架構,而且可以預期其他公司的人遇到類似問題應該也不會用這個方法解...

改用 IFTTT 分享到 Twitter

前面兩個月發文比較少,所以沒注意到 Jetpack 分享功能變成限制一個月只能分享 30 則,超過的部份要另外購買。這應該是 Twitter 之前在搞事的時候順勢推出來的專案?

看了一下應該是 Social 功能,Basic 版本就夠,但然後那個價錢應該是不太可能買 (年繳要 US$12/mo):

替代方案是把先前買的 IFTTT 拿出來用,透過 RSS feed 同步到 Twitter、LinkedInTumblr

本來的 PlurkFacebook 則是從 Twitter 同步過去,應該是不用動,來看一下效果怎麼樣...

玩最近 Facebook Research (Meta) 放出來的 LLaMA

很多地方應該都有提到 Facebook Research (Meta) 放出來的 LLaMA 了,對應的論文是「LLaMA: Open and Efficient Foundation Language Models」這篇,但這邊論文提到的 open 並不是一般常見的 open 定義,而只是常見的行銷詞彙而已,實際上只是 free for charging with constraints。

另外要注意 LLaMA 是個 LLM 而已,跟 ChatGPT 不算是同樣性質的東西,能對比應該是 GPT-3 (或是 GPT-3.5)。

主要是 ChatGPT 多了 SLRL 的步驟,而產出來的東西更接近商業化產品要的結果。

LLaMA 的特點在於效能不錯,可以用 LLaMA-13B 打贏 GPT-3 (175B),另外這次訓練出來最大的 LLaMA-65B 則可以站上第一梯隊 (與 DeepMindChinchilla-70BGoogle ResearchPaLM-540B):

LLaMA-13B outperforms GPT-3 (175B) on most benchmarks, and LLaMA-65B is competitive with the best models, Chinchilla-70B and PaLM-540B.

但跟以前差異最大的是,這次 Facebook Research 決定把訓練完後的 model 檔案放出來,所以就有了後續很多的進展:

We release all our models to the research community.

首先一開始 Facebook Research 要求使用者填表單才提供下載 (2/24 的時候),但三月初的時候 GitHub 上有人直接把 BitTorrentmagnet 連結附上去,送了一個 pull request:「Save bandwidth by using a torrent to distribute more efficiently #73」,所以你就有「方法」可以取得 model 檔案,但還是可以注意一下使用限制:

To maintain integrity and prevent misuse, we are releasing our model under a noncommercial license focused on research use cases. Access to the model will be granted on a case-by-case basis to academic researchers; those affiliated with organizations in government, civil society, and academia; and industry research laboratories around the world. People interested in applying for access can find the link to the application in our research paper.

除了可以透過 BitTorrent 下載外,comment 裡面也有 IPFS 的連結可以下載。

有需要下載這包檔案的人要注意檔案很大,大約 240GB,其中 65B model 佔了 128GB 左右。

被放出來以後就開始有很多人在上面包起來用,其中目前比較完整的應該是「Running LLaMA 7B and 13B on a 64GB M2 MacBook Pro with llama.cpp」這篇提到的方法,裡面提到的 ggerganov/llama.cpp 專案同時支援了 WindowsmacOSLinux,而且可以用 CPU 跑,速度也不慢。

試著用 llama.cpp 跑,65B 的 model 在家裡桌機有 64GB RAM 的情況下是可以應硬扛的,跑降到 4bits 的 model 大約吃 41GB RAM 左右。

比較驚訝的是 efficient 這個部份,拿 CPU 跑 65B 版本是跑得動的。

隨便丟個「文字接龍」進去 LLaMA-65B 讓他接,可以看到接出來的東西還可以:

main: prompt: 'The main difference between javascript and java are '
main: number of tokens in prompt = 10
[...]

The main difference between javascript and java are 1)Java is a compiled language while JavaScript
is not. So that the performance of Javascript code can be lower than Java Code, but they run on different platforms: browser vs server or local machine;
2)'javac' to compile .java file to bytecode(for JVM), and 'jar'(to make executable jar files for client systems).
3)Java uses more memory (RAM) that javascript. So the Javascript code is generally small than Java
codes.(A web application written in JavaScript may run faster on a PC with 64 MB of RAM compared to one running using applets.) While an advantage offered by J

如果是 LLaMA-7B 的話會快很多,但回答就有點微妙了:

main: prompt: 'The main difference between javascript and java are '
main: number of tokens in prompt = 10
[...]

The main difference between javascript and java are 1) Javascript is interpreted, while Java compiles to native machine code. (Compiled languages have a performance advantage over Interpreted ones
.)
2) The language standardization process for JavaScript has not been completed at the time of this writing which leaves it open to being hacked or changed by those who care enough about your website to do so... In Java, everything is set in stone. (Or at least as much code that can be shipped on a CD-ROM disk)
Sorry if my response was not clear - but you're right! I think that "2" above should really have said: "(

訓練所花的資源的部份,可以從論文裡面看到,如果是 2048 張 A100 的話大約要跑五個月 (照這個語氣,實際上大概不是這個數字):

Finally, we estimate that we used 2048 A100-80GB for a period of approximately 5 months to develop our models.

另外也有列出 GPU hours 可以參考:

Facebook 使用 AV1 的記錄

Facebook 整理了一份他們採用 AV1 的記錄:「How Meta brought AV1 to Reels」,要注意這邊的產品線是短影片類型。

因為之前剛好也有碰到 codec 這塊,但最後是因為 AV1 在 client 的支援度還跟不上,而選了在 Android 上支援度更好的 VP9

在文章前面有提到 server 端的需求,也就是 encoder 的部份,這是因為 AV1 的 encoding 真的很慢 (i.e. 外星技術),還在每過幾個月就會看到 encoder 技術重大突破的階段,所以得花時間去研究。

Facebook 後來決定用 SVT-AV1,因為效能上好很多 (以他們測試的那個時間點):

At any given point on the y-axis, SVT-AV1 can maximize encoding speed compared with any other production encoder. For example, the M8 preset is about as efficient as libvp9 preset 0, but M8 is almost 10 times faster.

而在 client 端的 decoder 部份,他們評估了 dav1dlibgav1 之後,選擇用 dav1d (iOS 與 Android 都是):

Two major open source software decoders are compatible with multiple platforms: dav1d was developed by VideoLAN and the open source community and can serve as an app-level decoder, while Google’s libgav1 is integrated into the Android SDK.

[W]e decided to integrate dav1d into the player for both iOS and Android platforms.

但在軟解的情況下只能解 720p30,然後中高階的才能解 1080p30,不過這對於短影片來說夠用:

dav1d can support 720p30 real-time playback on most of the devices in our sample, achieving 1080p30 on certain mid-range and high-end models.

所以就 Facebook 目前提供的資料來看,這部份還沒到輕鬆應對的情況,還得繼續看各家 library 的進展...

John Carmack 離開 Meta (Facebook)

這幾天另外一個比較大的人事變化,John Carmack 決定離開 Meta (Facebook):「I resigned from my position as an executive consultant for VR with Meta.」,裡面直接提到的是效率問題,但應該是搞不定政治問題。

接下來他會跑去搞自己在八月弄的新創 Keen Technologies,主打 AGI 主題,八月當時的新聞在這:「John Carmack’s AGI startup raises $20M from Sequoia, Nat Friedman, Patrick Collison and others」。

不過有個好奇的點,是這篇的 url 是不帶 encrypted tracking parameters 的,這是怎麼拿到的...

美國人使用社群媒體的情況

在「Social Media Usage by Age」這邊看到的文章,把美國人使用社群媒體的情況做成圖,資料來源是 Pew Research Center 的「Social Media Fact Sheet」這裡。

很明顯的可以看到 Google (Alphabet) 基本上就是 YouTube 一個產品吃天下,而 Facebook (Meta) 有三個產品在滲透,包括 Facebook、InstagramWhatsapp

LinkedIn 在出社會後會開始用,另外 Pinterest 這麼多老人家在用到是很驚奇 XDDD

掃 Instagram 資料的服務

Hacker News 首頁上看到「Scraping Instagram」這個掃 Instagram 資料的服務,討論在「Scraping Instagram (scrapingfish.com)」這邊。

文章裡面有提到一些 API 的技術細節,不過我覺得這塊倒不是重點,真正的重點應該是後端應該用了很多 IP 換來換去之類的技術在避開偵測...

另外這個服務讓我想到「HiQ Labs v. LinkedIn」這個案子 (之前寫過「hiQ 爬 LinkedIn 資料的無罪判決」),不確定 Instagram 這邊會不會提起訴訟,另外看起來這家公司好像也不在美國?

收費的部份是每千次 US$2,考慮到那堆架構的成本與麻煩度,好像還可以...