Vim 的後續計畫

在「Vim 作者 Bram Moolenaar 過世」後,Christian Brabandt 在「The future of the Vim project」這邊討論了 Vim 的後續計畫,主要是因為 Bram Moolenaar 算是主要的 coordinator,在他過世後大家需要確認彼此的權限,以及後續的共識。

目前這樣看起來是有在收斂,但我猜測在夠久的將來後會跟 Neovim 合併?至於會用誰的名字留下來就不知道了... 或是 Vim 專案後面沒有能量而被廢掉?

另外一個有趣的消息是這個:

Unfortunately, OSDN.net is apparently now being owned by OSChina and we currently do not have any support by OSDN.net or OSChina teams. @Shuji, thank you for maintaining the Vim Website since 2018 and all the best for the future!

翻了一下 OSDN 這個英文版的條目,沒寫到這件事情,是在日文版的條目 OSDN 上看到的。

Open Source Development Networkは、OSDN(オーエスディーエヌ)と略し、中国企業の开源中国(OSCHINA)が運営する、日本向けのオープンソースソフトウェアプロジェクト向けのホスティングサイト。かつてはSourceForge.netの姉妹サイトで、2015年5月11日にサイト名称がSourceForge.JPからOSDNに変更された。

翻了一下新聞,看起來是 2022 年的事情:『「OSDN」が中国企業に買収 ~日本のオープンソースプロジェクト ホスティングサービス』。

Georgi Gerganov 成立公司 GGML

Hacker News 首頁上看到 Georgi Gerganov 成立公司的計畫:「GGML – AI at the Edge (ggml.ai)」,官網在「GGML - AI at the edge」。

如同 Georgi Gerganov 提到的,llama.cpp 這些專案本來是他的 side project,結果意外的紅起來:

另外他提到了 Nat FriedmanDaniel Gross 也幫了一把:

在官網則是有提到是 pre-seed funding:

ggml.ai is a company founded by Georgi Gerganov to support the development of ggml. Nat Friedman and Daniel Gross provided the pre-seed funding.

現在回頭來看,當初 llama.cpp 會紅起來主要是因為 CPU 可以跑 LLaMA 7B,而且用 CPU 跑起來其實也不算慢。

後來吸引了很多人一起幫忙,於是有了不少 optimization (像是「llama.cpp 的載入速度加速」這邊用 mmap 減少需要載入的時間,並且讓多個 process 之間可以重複使用 cache),接下來又有 GPU 的支援...

但不確定他開公司後,長遠的計畫是什麼...?

用 RSS-Bridge 接服務

查資料的時候發現 RSS-Bridge 這個用 PHP 寫的專案,直接找個 PHP hosting 架起來就可以用了,沒有什麼其他的需求。

簡單架起來測了一輪,看起來不賴啊,如果一般人要用的話可以考慮就用這個專案就好,量很少的人可以用官方列出來的 Public instances 玩一下,量多的人可以自己架,PHP hosting 還蠻好找的,官方要求要 7.4+,注意一下 PHP hosting 提供的版本應該不會有太多問題。

自己寫的 feedgen 比較偏順便練 Python,不過當時的確是還不知道有這樣的專案,看了一下 GitHub 上的 tag 記錄,2013 就有的專案...

用 Perl 把 log 丟上 Slack

因為想在 Raspberry Pi 上面把一些 log 丟上 Slack,本來看到「Stream Any Log File to Slack Using curl」這篇,但發現裡面在把字串包進 JSON object 的方法太髒 (直接把 " 換成 '),另外一方面是 Slack 已經在宣導不要用舊版的 Incoming Webhooks,所以決定用其他方式來處理。

選擇 Perl 主要是因為有一陣子沒有用 Perl 寫東西了,倒不是什麼特別的原因 (如果考慮到 Raspberry Pi 上資源有限的話,應該用 C 或是 Rust 或是 Go,但我的 Raspberry Pi 還沒忙到這種程度...),所以決定用 Perl 來實做這個程式,把 log 檔案丟上 Slack:

這邊有些比較不太常見的選擇:

  • 不用 File::Tail 而反而是用 pipe 的方式取得 tail -F 的輸出,是因為 File::Tail 非常舊了 (2015),實做上沒有用到 inotify 類的界面監控檔案的變化,反而是系統的 tail 有做。
  • JSON::PP (pure perl 版本) 而不是 JSON 是因為 JSON::PP 在 Perl 5.14+ 後內建了,我沒有太在意效能,這也是上面放 use v5.14 的原因。
  • 這邊的 API 呼叫還是選擇了 WWW::Mechanize 是因為沒有內建的套件可以處理 HTTPS 連線 (可以參考 Perl core modules 這邊),既然要另外安裝,就裝個支援度比較完整的 libwww-mechanize-perl 來用。

然後查了一下 // 的用法在 Perl 5.10+ 就支援了,好早...

關於 twemoji.maxcdn.com 這個網址的一些事情

在「phpBB 3.3.10 Release」這邊看到這個修正,研究了一下發現原來有些故事在後面跑:

Update the emoji CDN: PHPBB3-17071

Twitter Emoji (Twemoji) 這個計畫是 Twitter 弄出來的 open source project,最主要是讓不支援新版 Unicode 的系統上可以改用圖片顯示出來 (畢竟 Unicode 一直在加字)。

其中提供的 url 是 https://twemoji.maxcdn.com/v/latest/twemoji.min.js,可以看到裡面帶有 MaxCDN 的資訊,算是一種廣告,但後來 StackPath 在 2016 併購 MaxCDN,接下來是在去年打算要淘汰掉 MaxCDN 這個產品線:「MaxCDN and SecureCDN are Retiring; Here’s What It Means for You」。

這件事情被帶到「Clarify MaxCDN URLs now that MaxCDN is retiring #556」這邊討論,但看起來沒有太多動作,後來在「Maxcdn has shut down, cdn not working anymore. #580」這邊又被帶起來討論,其中 Twitter 前員工大概提了一下情況,主要是當年他們跟 MaxCDN 有談過讓 MaxCDN 負責頻寬的部份:

@simplexx among all the things, twemoji has always been a Twitter service for the community.

At my times in there, we had a great agreement / deal with MaxCDN so that it's hard to blame the boss this time, as MaxCDN is a completely different company/story.

What I see is some poor attention to this project, as companies don't close from a day to another (usually?) but as we all know what's going on @ twitter, I can't really blame any of my former colleagues, or new arrivals there.

Please let's not make it a wall of shame for all the people that worked on this, thanks for your understanding (I've left 7 years ago or more, as example, I've got pinged by some follower and I'm just trying to help you out anyway).

另外也有人提到目前 Twitter 的溝通管道的狀況:

For what it's worth, while I was still there we were in talks with MaxCDN to have the same deal when they migrated to be Stackpath. Everyone who had worked on the deal with MaxCDN had left and left no record of that deal, so it was taking them a bit longer to work out than expected – MaxCDN used to offer free hosting to OSS projects, but Stackpath wouldn't be doing that. They were working on an exception for us, but any emails they send to our Twitter emails now get bounced, so I guess they could've gotten this sorted out before shutting down MaxCDN... but it's not like we're there on the other end to make it happen, so it appears we'll never know.

Anyway,現在是至少讓 twemoji.maxcdn.com 恢復到「會動」了,但情況變得很特殊,twemoji.maxcdn.com 這個網址目前是指到競業的 BunnyCDN 上:

;; ANSWER SECTION:
twemoji.maxcdn.com.     229     IN      CNAME   twemoji.b-cdn.net.
twemoji.b-cdn.net.      35      IN      A       23.248.177.58

但如果你真的打過去要檔案,會是 301 到 jsDelivr 上:

$ http https://twemoji.maxcdn.com/2/svg/1f525.svg
[...]
Location: https://cdn.jsdelivr.net/npm/twemoji@11.3.0/2/svg/1f525.svg
[...]

而 jsDelivr 目前是放在 Fastly 上:

;; ANSWER SECTION:
cdn.jsdelivr.net.       180     IN      CNAME   jsdelivr.map.fastly.net.
jsdelivr.map.fastly.net. 30     IN      A       199.232.45.229

但在 GitHub 的說明上面則是建議用 UNPKG

<script src="https://unpkg.com/twemoji@latest/dist/twemoji.min.js" crossorigin="anonymous"></script>

而 UNPKG 目前的 CDN 的部份則是 Cloudflare

;; ANSWER SECTION:
unpkg.com.              86400   IN      NS      anirban.ns.cloudflare.com.
unpkg.com.              86400   IN      NS      aron.ns.cloudflare.com.
;; ANSWER SECTION:
unpkg.com.              300     IN      A       104.16.126.175
unpkg.com.              300     IN      A       104.16.123.175
unpkg.com.              300     IN      A       104.16.122.175
unpkg.com.              300     IN      A       104.16.124.175
unpkg.com.              300     IN      A       104.16.125.175

指到 BunnyCDN 但是 BunnyCDN 只負責 redirect,然後也不是導到 UNPKG 上...

從 Android (AOSP) fork 出來的 /e/

上個禮拜在 Hacker News 看到的「Review of /e/ – An Android Alternative For Mobile Phones」,在講 /e/ 這個從 AOSP 改出來的作業系統,主力在於「unGoogled」這件事情,避免任何資料傳回給 Google。Hacker News 上對應的討論在「Review of /e/ – Android-based alternative for mobile phones (thenewleafjournal.com)」這邊。

先看了一下運作方式,/e/ 的後面是 e Foundation,以非營利組織的方式經營。

LineageOS 的經驗來看,看起來有蠻多東西預先包好了,像是預掛了 microG 來模擬 Google Play Services 的服務與 API,這樣可以讓一些需要 Google Play Services 的服務可以跑 (但可以預期不會是完全相容)。

另外也有一些商業合作,所以市場上可以買到出廠就已經安裝 /e/ 的手機,讓一般使用者更容易上手。另外一條可以預期的路是自己刷 /e/,從「Smartphone Selector」這邊可以看到 /e/ 支援很多型號。

文章裡另外題到了其他的 AOSP fork,走不同的路線:

In addition to LineageOS, there are two forks focused primarily on security – GrapheneOS and CalyxOS. There is also Replicant, which appears to mostly support older devices at this time.

看起來弄個 Pixel 5a 或是舊一點的 Pixel 4a 應該是個還可以的方向,Google 自家牌的手機通常都是這些 distribution 優先支援的機種...

獨立遊戲創作者推出 Linux 版的好處

標題不知道怎麼下,大概就是這樣...

Hacker News 首頁上翻到的,以這個 upvote 數量來看,應該會收到今天的 Hacker News Daily 上:「Despite having just 5.8% sales, over 38% of bug reports come from Linux (reddit.com)」。

作者是一位獨立遊戲開發者,在兩年前推出了「ΔV: Rings of Saturn」這款遊戲,並且也發佈了 Linux 版。

作者先就數字來比較,他賣出了 12000 套,其中 700 套是 Linux 玩家;另外他收到了 1040 個 bug report,其中大約 400 個是從 Linux 玩家回報的:

As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.

That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.

看文章時可能會覺得「Linux 玩家真難伺候」,但實際上作者講到,這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上),其他的 bug 其實是所有平台都會發生:

A lot of extra work for just 5.8% of extra units, right?

Wrong. Bugs exist whenever you know about them, or not.

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]

原因是 Linux 社群在參與各種 open source project 養成的習慣,會盡可能把各種資訊講清楚,並且找出可以重製問題的方式:

The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

But that’s not all. The report quality is stellar.

與一般玩家的回報方式完全不同,Linux 玩家很習慣就會附上基本的環境資訊,系統紀錄,甚至有時候還會包括 core dump 與 reproducible steps:

I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.

And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

不知道有沒有遇到回報 GDB 資訊的...

很特別的分享 XDDD

GitHub 對 Issues 增加了一些新功能

GitHub 推出了 Issues 的 beta program:「GitHub Issues · Project planning for developers」。

目前列出來的新功能裡,Board 與 Table 呈現方式 (Bored of boards? Switch to tables.),以及 Subticket 的功能 (Break issues into actionable tasks),這兩個算是在 project management 裡面很重要的功能,不過整體還是很陽春,只能說補上了一些重要的元素...

另外這次的 beta program 算是宣示 GitHub 有投入資源在改善 project management 這部份的功能,也許之後也許會有其他新功能繼續推出?

Mattermost 推出可以自己架設的專案管理工具 Focalboard

Mattermost 推出了可以自己架設專案管理的工具 Focalboard,在 Hacker News 上可以看到討論:「Focalboard – a self-hosted alternative to Trello, Notion, and Asana (focalboard.com)」。

從界面上可以看出來抄 Notion 的專案部份,目前的功能還非常早期,沒有什麼整合能力... 然後從這個產品可以知道,這家公司應該就打算一直抄下去了 XD

GitHub 上的資料看起來是 GolangVue.js 寫的,設定裡看起來支援 PostgreSQLSQLite

預設的 telemetry 是開的 (在 config.json 裡面可以看到),建議可以關掉...

Open Source 專案的 Office Hour

Simon Willison 提出了一個想法,認為 Open Source 專案可以透過 Office Hour 的方式幫助社群:「Open source projects: consider running office hours」,順帶一提的是,本來的標題是「Open source projects should run office hours」,在 Hacker News 上有些人看不爽,所以就改掉了,討論串在「Open source projects should run office hours (simonwillison.net)」這邊可以看到。

Office Hour 這個詞不知道出自哪裡,不過在大學的時候常常用到,主要是教授或是助教會安排一個固定的時間與地點,讓學生可以過去發問。

社群也有類似的作法,像是 WikimediaIRC office hours,是線上的形式,透過 IRC 溝通。

如果是商業公司主導的 open source 專案應該是可以考慮的方法,有地方可以問的確會方便不少。