查詢 GitHub 上面 repository 的公開記錄

起因應該是「Claim: Private GitHub repos included in AI dataset (lurk.org)」這邊的討論,原文是 @emenel@post.lurk.orghttps://post.lurk.org/@emenel/112111014479288871 這邊宣稱他在 GitHub 的 private repository 被當作 training data 蒐集走使用。

而 GitHub 有公開全站的 public event data,所以 Simon Willison 就拿這份資料直接組了一個工具出來用:「GitHub Public repo history」。

這樣可以直接 auditing 對應的說法,不過看了一下 GitHub 上的帳號 emenel (上面連結是到同一個站,應該是同一個人),目前看起來已經把所有 repository 都刪掉了...

查詢 Debian 與 Ubuntu 官方的 apt repository 的版本資訊

因為在寫「Python 3 的支援週期」這篇時需要查不同作業系統版本下的 python3-minimal 版本資訊,一開始是到 packages.ubuntu.com 上查,但上面只列出了目前還有支援的作業系統的套件。

所以就到 Ask Ubuntu 上面問:「How to search package information on unsupported Ubuntu distribution」。

看起來有兩個方法可以拉到歷史資料,一個是 devscripts 裡面的 rmadison,直接帶入要查的套件名稱就可以了:

$ rmadison python3-minimal

另外一個是到 https://ubuntu-archive-team.ubuntu.com/madison.cgi 這邊查,這個位置也是 rmadison 預設的 backend,資料應該是一樣的。

而加上 -u debian 可以改查 Debian 這邊的資訊,用 -h 可以看到還有那些 alias 可以用。

目前 Ubuntu 這邊可以查到最舊的版本是 trusty (14.04),如果要更舊的版本資訊,需要去 launchpad.net 上面翻,像是 https://launchpad.net/ubuntu/precise/+package/python3-minimal 這個。

在 PPA 裡面只安裝特定軟體的方式

Ubuntu 20.04 的 rsync 內建只有 3.1.3 (參考「Ubuntu – Package Search Results -- rsync」這邊),但 --mkpath 這個參數需要 3.2.3+ 才能跑:「How can I configure rsync to create target directory on remote server?」,所以就要找 PPA 看看有沒有人有包新版的可以用。

在「Utilities - various (Xenial & newer)」這邊可以看到 Rob Savoury 有包,但發現這包有一堆軟體,我不想要裝這麼多,所以就用 Pinning 限制。

apt-cache policy 可以看到 o= 的值,然後就可以在 /etc/apt/preferences.d/savoury1-utilities 裡設定 rsync 的 Pin-Priority1001,而其他的都掛到 -1

Package: *
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: -1

Package: rsync
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: 1001

但跑 apt upgrade 沒看到可以升級,而直接 apt install rsync 的時候可以看到是因為 libxxhash0 跟不上新版而產生錯誤訊息:

The following packages have unmet dependencies:
 rsync : Depends: libxxhash0 (>= 0.8.0) but 0.7.3-1 is to be installed
E: Unable to correct problems, you have held broken packages.

所以一起加進去變成:

Package: *
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: -1

Package: libxxhash0 rsync
Pin: release o=LP-PPA-savoury1-utilities
Pin-Priority: 1001

然後就可以 apt upgrade 升級上去了。

GitHub 宣佈將在 2024 移除對 Subversion 支援

GitHub 從 2010 年的愚人節時宣佈支援 Subversion:「Announcing SVN Support」,雖然是愚人節的功能,但這個功能是會動的。

而這個功能出現十多年後,可以預期用的人愈來愈少。前幾天 GitHub 宣佈將在大約一年後的 2024/01/08 停止支援 Subversion:「Sunsetting Subversion support」。

然後在 Hacker News 上的討論「GitHub Sunsetting Subversion Support (github.blog)」則是直接讓 Scott Chacon (GitHub co-founder,同時也是第一篇公告文的作者 + 這個功能的兇手之一) 出來解釋當初搞出這個東西的前因與後果,還有一些感想。

裡面有提到這個功能當初推出來的時候是個好玩的性質,但意外的在上線後發現也讓一些老系統可以比較容易轉移:也就是讓 developer 可以先開始用 Git,但 CI 類的工具可以先不用改。

As one of the GitHub cofounders and the brainchild of this particular feature, I want to let everyone know that this is maybe the funniest thing I've ever done.

We released this feature and published the announcing blog post, on April Fool's Day, 2010. I remember demoing it to the other GitHub guys and saying how funny it would be if we made this an April Fool's day post as though it was a big stupid joke but then it actually completely worked on every repository we had and we all thought it would be great. Until nobody believed us. Which in hindsight we should have seen coming, since that was the joke, but nobody actually tried it. Then people tried it and it worked and they thought it was a trick or something.

It was really helpful for people migrating from legacy SVN based systems to us (CI and stuff) but I'm surprised to some degree that it's still running 13 years later when nobody is really facing that issue anymore. And I'm still undecided if the joke was worth the massive confusion it caused. But if I'm pressed, I would say that I would 100% release it on April Fool's Day again.

不過想要拔掉這個功能的起因不知道是什麼,技術債不知道有多少...

用 reprepro 建立 APT repository

在「用 fpm 這個工具包 .deb 安裝」這篇題到了 fpm,另外在同一篇文章裡面 (「Using Cloudflare R2 as an apt/yum repository」這篇) 也有提到要怎麼生出一個有簽名過的 APT repository,裡面就提到了 reprepro 這個工具。

Debian Wiki 上面的「SetupWithReprepro」就有一步一步告訴你設定的方式,另外 Wikimedia 的技術 wiki 上也有提到常用的操作:「Reprepro」。

然後可以丟到很多不同的地方,最常見的 apache 或是 nginx 外,S3 或是其他可以吐 HTTP/HTTPS 的 object storage 服務都可以。

也是先記錄起來,等要用的時候可以回來 blog 上翻到...

用 Git 2.38 內建的 Scalar 管理大量的 repository

在「Highlights from Git 2.38」這邊有介紹 Git 2.38 加入了微軟開發的 Scalar,是一個用來管理大量 repository 以及巨大 repository 的工具。

第一次用 scalar register 看起來會先有一些前置作業,在掛 repository 進去的時候就會自動去註冊 timers:

Created symlink /home/gslin/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer → /home/gslin/.config/systemd/user/git-maintenance@.timer.
Created symlink /home/gslin/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer → /home/gslin/.config/systemd/user/git-maintenance@.timer.
Created symlink /home/gslin/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer → /home/gslin/.config/systemd/user/git-maintenance@.timer.

這樣看起來應該是每個小時會跑一些東西?文件上看起來是會在背景先去拉一些東西,還有定時跑 GC?

接下來就是把目錄下所有的 git repository 丟進去:

find . -maxdepth 1 -mindepth 1 -type d | xargs -n1 -I% bash -c "cd %; scalar register"

然後可以用 scalar list 看到目前掛了哪些 repository。

Git 2.37.0 對巨大 Monorepo 的加速功能 FSMonitor

這邊用 GitHub 寫的說明好了:「Improve Git monorepo performance with a file system monitor」。

從 2.37.0 開始,Windows 與 Mac 版的使用者可以透過 FSMonitor 的功能記錄檔案系統的變化,大幅減少需要 scan 整個 repository 的時間,可以看到啟用後對於像是 chromium 這種大型專案的 status 時間就大幅下降了:

不過 Linux 還沒支援,目前我的環境都是 Linux,就沒辦法用了...

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用,剛剛翻了一下 NomadVault,看起來都支援 APT repository 了:「https://apt.releases.hashicorp.com」;另外也有 RPM repository:「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構,從錯誤訊息觀察,看起來後面是 Amazon S3,前面是 Fastly 的 CDN。

把 blog 搬到 t4g.small 上

算了一下成本還可以接受 (機器 + 空間 + 流量),就把 blog 搬到 AWSt4g.small (ARM) 上,理論上頁面的速度應該會快不少,過幾天等穩定性沒問題後就來買 RI...

x86-64 轉到 ARM 上面,主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository,所以就改用 MariaDB 了。

其他的倒是都差不多,目前的 Ubuntu + nginx + PHP 沒什麼問題,跑一陣子看看...

youtube-dl 的恢復與後續 GitHub 的處理模式

youtube-dl 被下架的事情後續又有不少進展了 (先前寫過「youtube-dl 被 RIAA 用 DMCA 打下來的事件」這篇),主要是 GitHub 恢復了 youtube-dl 的 Git Repository,然後丟出了一篇文章解釋過程,以及後續的作法:「Standing up for developers: youtube-dl is back」。

要注意這次的事件完全是法律戰,所以裡面發生的敘述都是各自的說法,大家可以自己解讀...

GitHub 的這篇文章是由 Abby Vollmer 發表的,從 LinkedIn 上的資料也可以看到他以前的經歷都是法律相關,現在在 GitHub 的頭銜是「Director of Platform Policy and Counsel」,而這篇的用字也可以看出來很小心。

首先 GitHub 認為下架的原因是 Section 1201:

Section 1201 dates back to the late 1990s and did not anticipate the various implications it has for software use today. As a result, Section 1201 makes it illegal to use or distribute technology (including source code) that bypasses technical measures that control access or copying of copyrighted works, even if that technology can be used in a way that would not be copyright infringement. Circumvention was the core claim in the youtube-dl takedown.

而 GitHub 後續恢復 youtube-dl 的原因是收到 EFF 代表 youtube-dl 開發者所做的 counter notice:「2020-11-16-RIAA-reversal-effletter.pdf」。

照以往這種把事情搞超大的慣例,RIAA 應該是不會有後續的動作,所以就 youtube-dl 這件事情來說應該是差不多告一段落。

GitHub 後續針對 Section 1201 提出了兩個改善措施,一個是重新設計 Section 1201 的處理方式,另外一個是 GitHub 自己投入資金,降低 developer 的負擔。

但整件事情背後的問題主要是在 DMCA 的設計,讓濫發 takedown notice 的人很難受罰,在這點沒有改善之前,同樣的劇碼應該都還是會繼續上演。