Tom 除錯中

有興趣但是還沒研究的東西

25 min read

Zen Browser - 類似 Arc 瀏覽器，但是使用 Firefox Gecko engine 的開放原始碼瀏覽器

糾結了很久 Chrome 和 Arc，最終選擇了 Librewolf

Librewolf 是一款基於 Mozilla Firefox 開發的瀏覽器。Firefox 本身是一款很優秀的開放原始碼軟體，其優點可見下圖。

Librewolf 則在此基礎上增加了一些高級的隱私保護設定，方便普通使用者使用

最終，選擇從 Chrome 換成 Libreworf 有以下幾個原因：

  • 常用的 Chrome 外掛都能在 Librewolf（Firefox 外掛商店） 上找到，使用體驗與過去一致。Arc 的標籤頁邏輯我一直不習慣；
  • 我的 Chrome 瀏覽器一直有奇怪的 Bug：在第三方平台登錄Google帳號偶爾會登錄不進去報錯，Safari 則可以；
  • Arc 的側邊欄體驗很好，而 Sidebery 能實現類似的功能，並提供樹狀的標籤頁結構，設定請參考：組態 Firefox 垂直標籤欄。設定完成後介面很乾淨（見下圖）；
  • Firefox 核心的瀏覽器能耗更低。這是個奇怪的需求，但確實需要。我出差的時會攜帶一款 65w 的充電器，軟體開的比較多的時候，會出現充不進電的情況；
  • 本想選擇 Firefox （小狐狸太可愛了），但 Libreworf 的隱私設定開箱即用，實在方便。如果使用 Firefox，日後我可能還會想再折騰一次；
  • 新鮮感；
  • 隱私很重要：Why Do I Care So Much About Privacy?；
  • Librewolf 默認不播放任何 DRM 內容。YouTube 沒有對創作者的視訊進行 DRM 保護，但卻對他們的商業廣告進行了 DRM 保護。因此，使用 Librewolf 可以完全免費地享受無廣告的 YouTube 視訊體驗；
  • 開放原始碼軟體很酷。如果兩款軟體提供相似的體驗，我會選擇開放原始碼的那個。

Firefox 外掛

Libreworf 使用的是 Firefox 外掛商店。

  • Bypass Paywalls Clean，用於繞過付費網站的付費牆，訪問受限制的內容。
  • ChatGPTBox，總結網頁內容。
  • ClearURLs，隱私工具，可以自動刪除 URL 中的跟蹤參數和不必要的中繼資料。
  • Clip to DEVONthink，將 Web 頁面上的內容剪下並保存到 DEVONthink。
  • Content Farm Terminator，識別內容農場網站，這些網站通常以低品質的內容和廣告為主。
  • Copy PlainText，從網頁中複製純文字。
  • Dualsub，在視訊中顯示兩種語言的字幕。
  • EasyScholar，顯示科研論文的影響因子和分區。
  • Enhanced GitHub，最佳化 GitHub 瀏覽和使用體驗。
  • Enpass Password Manager，密碼管理器。
  • Google Scholar Button，快速訪問 Google 學術搜尋引擎。
  • Humble New Tab Page，自訂新標籤頁。
  • I don’t care about cookies，停用網站的 cookie 通知，以提高瀏覽體驗。
  • Immersive Translate: Web Page&PDF Translation，用於網頁和 PDF 翻譯的外掛。
  • MetaMask，加密貨幣錢包外掛。
  • Readwise Highlighter，將文章匯入 Readwise Reader，並高亮和批註。
  • Sidebery，樹狀結構的瀏覽器標籤頁側邊欄，設定請參考：組態 Firefox 垂直標籤欄。
  • Tampermonkey，指令碼管理器，自訂網站的行為和外觀。我使用的指令碼如下圖所示，已備份上傳到 Github。
  • UBlock Origin，廣告遮蔽軟體。
  • V2EX Polish，最佳化 v2ex 瀏覽體驗。
  • Zotero Connector，Zotero 文獻管理軟體的瀏覽器外掛，收集、管理和引用學術文獻和資訊。
  • SearX，更改了默認搜尋引擎。

Ngrok 的開源替代方案 frp

wruby 僅有一個 ruby 檔案的靜態部落格程式

用 PostgreSQL 取代 MongoDB

不用 .env 改用 vault service

dotenvx

…這十年下來已經知道把 secret 放在環境變數裡太容易洩漏… 目前被提出來比較好的方法是把 secret 都放到 vault service 裡面，由 vault service 給一把讀取用的 API key，放進 dotenv 或是其他地方 (被稱為 secret zero)。

這樣這把 API key 去 vault service 抓取真正的 secret 放到程式內的物件取用 (像是資料庫的帳號密碼)，而不是環境變數。

vault service 解決方案：

想色色就去 Web3？

成人內容平台審查嚴、銀行擋付款，OnlyFans明星投奔鏈上世界

想色色就去 Web3？成人內容平台審查嚴、銀行擋付款，OnlyFans明星投奔鏈上世界

Patreon 的創作者在提款時遭銀行誤判為詐騙，使他們遭受困擾:

Hey, if you’re a Patreon creator and are confused as to why a bunch of your income vanished, it’s because Patreon’s system appears to have totally collapsed. They sent me an email saying my credit card blocked the payment as fraudulent, and CANCELLED ALL OF MY CREATOR SUPPORT.

https://twitter.com/JasonKPargin/status/1686783605551382530

I told the credit card company the charge was valid, fine. Patreon sent an email saying “click here to update your payment” and that link goes to a 404 error. My list of supported creators is gone, I have to try to remember who I was supporting - there is nothing on the site

https://twitter.com/JasonKPargin/status/1686783937111015424

2022 年，OnlyFans 模特 Allie Rae 推出了基於加密貨幣的成人內容平台 WetSpace，意在替代 OnlyFans。Rae 表示，創立此平台是為了避免銀行的干預，認為加密貨幣提供了一個很棒解決方案。

近期，也有越來越多的 OnlyFans 創作者轉投基於 Layer2 Base 所建立的去中心化社交平台 Friend.tech。

Friend.Tech用戶大量退出，Web3社交的友誼小船說翻就翻？

所以雞蛋不要放在同一個籃子裡，要有備份帳號，作品要自己備份好 (AWS S3 Storage Class – Glacier Deep Archive、隨身硬碟)

我如何將開源專案變成一項業務

https://docs.emailengine.app/how-i-turned-my-open-source-project-into/

(以下是 Google 翻譯，下一個 comment 是英文原文)

大約 15 年前，當我開始編寫和發布開源軟體時，我對此非常激進。我只使用像 MIT 或 BSD 這樣的寬鬆許可證，因為我只關心可及性。使用帶有附加條件的 Copyleft 許可證似乎阻礙了這一範圍。讓另一家 A 類公司使用我的開源程式庫（例如Nodemailer）是一種榮譽徽章。我甚至當一家主要交易電子郵件服務的創始人向我發送了一封有關 Nodemailer 的電子郵件並提出捐款以促進我的努力時，我拒絕了。我不想顯得受到主要提供者之一的影響，因為這對其他提供者不公平。

事後看來，我真是個傻瓜。

無論如何，幾年後，當一家使用 Nodemailer 的新創公司被以 5 億美元收購時，情況發生了變化。那時我的經濟狀況並不好，當我看到這個新聞時，我開始想──我從中得到了什麼？發送電子郵件通知是該服務的重要組成部分，他們可能每天使用 Nodemailer 發送數百萬封電子郵件通知。至少，我透過提供一個免費且可靠的庫來發送這些電子郵件，為他們節省了大量的開發時間。我在信箱中搜尋了與該公司相關的電子郵件，並發現了一封針對某項功能的投訴。沒有拉取請求，沒有捐贈，什麼都沒有。而且也沒有什麼好抱怨的，因為我故意將我的軟體提供給全世界使用，而不要求任何補償。我空空的錢包對事態的發展並不滿意。

因此，當我開始最終成為 EmailEngine 時，我試圖盡可能地掩護自己。我在 Copyleft LGPL 授權下發布了該軟體。我還設定了一個自動化的 CLA 流程，讓任何人都無法在不先簽署 CLA 的情況下合併他們的 PR。許多人討厭 CLA，有幾個人首先創建了 PR，但在意識到存在 CLA 要求後就將其關閉。嗯，說實話，我並不太在意。例如，Nodemailer 98.1% 的程式碼是我自己寫的，只有 1.9% 來自其他貢獻者，因此 PR 合併不是什麼大問題。對於 EmailEngine，在開源發布一年半後，相同的數字分別為 99.8% 和 0.2%。

我使用CLA 助理來管理專案中的 CLA (Contributor License Agreements)

顯然，我想從我的新專案中賺點錢，而且我的商業計劃很簡單。我將該專案（當時稱為 IMAP API）作為 LGPL 許可的應用程式發布。我還提供了 MIT 版本，但要獲得該版本，您必須訂閱。訂閱費為每年 250 歐元。我的假設是，公司（該軟體的主要目標）不喜歡 Copyleft 許可證，一旦他們看到該應用程式有多有用，就會轉換為寬鬆許可證。

好吧，事實證明我的商業計劃很瘋狂。我只獲得了一些付費訂閱者，而且在我看來，這些人甚至沒有使用 IMAP API。他們只是想支持我的努力。事實證明，小公司根本不關心許可證，而大公司也沒有使用它。經過一年半的總收入 750 歐元後，我決定跳槽——提供免費的東西已經足夠了。

我重新設計了應用程式的使用者介面，使其看起來更專業，並實施了許可證密鑰系統。從那時起，如果您想使用 EmailEngine（IMAP API 的新名稱），您需要一個僅適用於付費訂閱者的許可證金鑰。我還將許可證從 LGPL 更改為商業授權。原始碼仍然在GitHub 上公開發布。根據定義，它不再是開源的，而是原始碼可用的。這種許可證變更之所以可能，是因為要求外部提交者從一開始就簽署 CLA。

我仍然發布麻省理工學院許可的項目，但僅限於較小的工具，而不是較大的項目。這些工具的目標是促進我的主要努力。例如，我從 EmailEngine 中提取了 IMAP 用戶端函數，並在 MIT 授權下將其發佈為 Node.js 的通用 IMAP 用戶端程式庫。這個模組（ImapFlow）正在獲得越來越多的採用，因為它比任何現有的替代方案都要好得多。文件頁面每月向 EmailEngine 的主頁發送大約 100 名訪問者，雖然不多，但是嘿，這是免費流量，有時這些訪問者確實會發生轉化，使努力富有成果。 起初，甚至沒有試用選項。如果您在應用程式啟動後 15 分鐘內未提供有效的許可證金鑰，則該應用程式將停止運作。

我保持價格不變，每年 250 歐元，第一個月，我賣出了價值 1750 歐元的訂閱。這相當於我前一年半賺的錢的兩倍，它決定了這個專案的命運。沒有回頭路了。

接下來，我開始提高定價；250 歐元變成了 495 歐元，然後是 695 歐元、795 歐元，最後是 895 歐元。令我驚訝的是，這並不意味著客戶數量減少。我想對企業來說任何低於 1000 美元的金額都是微不足道的，因此價格上漲唯一改變的是收入的增加。

目前 EmailEngine 的 MRR (每月經常性收入)為 6100 歐元，並且穩定增長，在我居住的愛沙尼亞，這使我能夠支付自己一份體面的薪水，以便我可以全職從事我的專案。我唯一的遺憾是我沒有早點開始銷售我的軟體並且只發布免費的開源軟體。是的，我在 GitHub 上有一些贊助商，但金額從來都不是很大，每月 50-750 美元不等，具體取決於我碰巧有多少贊助商。向商業客戶銷售肯定比依賴隨機人員的善意更可靠和可預測。

How I turned my open-source project into a business

When I started writing and publishing open-source software about 15 years ago, I was pretty radical about it. I only used permissive licenses like MIT or BSD, as all I cared about was reach. Using a copyleft license with strings attached seemed to hinder that reach. Getting another A-category company to use my open-source libraries like Nodemailer was a badge of honor. I even went so far that when a founder of a major transactional email service sent me an email regarding Nodemailer and offered to make a donation to promote my efforts, I rejected it. I did not want to seem affected by one of the dominant providers because this would not be fair to other providers.

In hindsight, what a fool I was.

In any case, it changed years later when a startup using Nodemailer was acquired for half a billion dollars. I was financially not in a good place back then, and when I saw the news, I started to wonder – what did I get out of this? Sending email notifications was a huge part of that service, and they probably sent millions of email notifications a day using Nodemailer. At the very least, I saved them tons of developer hours by providing a free and solid library for sending these emails. I searched my mailbox for emails related to that company and found a single complaint about a feature. No pull requests, no donations, no nothing. And there was nowhere to complain either as I had knowingly given my software for the world to use with no requirements to compensate anything. My empty wallet was not happy about the turn of events.

So, when I started what eventually became EmailEngine, I tried to cover my back as much as possible. I released the software under the copyleft LGPL license. I also set up an automated CLA process so that no one was able to get their PR merged without signing a CLA first. Many people hate CLAs, and several persons opened a PR first but closed it once they realized that there was a CLA requirement. Well, to be honest, I didn’t really care. For example, 98.1% of the code for Nodemailer was written by myself, and only 1.9% was from other contributors, so not getting PRs merged was not a major issue. For EmailEngine, after a year and a half of being published as open source, the same numbers were 99.8% vs 0.2%.

I use CLA assistant for managing CLAs in my projects Obviously, I wanted to make some money from my new project, and my business plan was simple. I published the project (it was called IMAP API at that time) as an LGPL-licensed application. I also offered an MIT version, but to get that, you had to subscribe. The subscription fee was 250€ per year. My assumption was that companies - the main target for the software - do not like copyleft licenses and would convert to the permissive license once they see how useful the app is.

Well, it turns out my business plan was bonkers. I only gained a few paying subscribers, and it seemed to me those people weren’t even using IMAP API. They just wanted to support my effort. It turned out that smaller companies did not care about the license at all, and larger companies were not using it. After a year and a half and 750€ in total revenue, I decided to jump ship — enough of providing free stuff.

I re-designed the UI of the app to look more professional and implemented a license key system. From that moment if you wanted to use EmailEngine (the new name for IMAP API), you needed a license key that was only available for paying subscribers. I also changed the license from LGPL to a commercial license. The source code is still published publicly on GitHub. It is no longer open-source by definition but source-available. This change of license was only possible due to requiring outside committers to sign a CLA from the start.

I still publish MIT-licensed projects, but only for smaller tools, not larger projects. The goal of these tools is to promote my main effort. For example, I extracted the IMAP client functions from EmailEngine and published it under an MIT license as a generic IMAP client library for Node.js. This module (ImapFlow) is gaining steam in adoption as it is by far better than any pre-existing alternative. The documentation page sends about 100 visitors per month to EmailEngine’s homepage, which is not much, but hey, it is free traffic, and sometimes these visitors do convert, making the effort fruitful. At first, there wasn’t even a trial option. If you did not provide a valid license key 15 minutes after the application started, the app just stopped working.

I kept the price the same, 250€ per year, and during the first month, I sold 1750€ worth of subscriptions. That’s like twice the amount I made in the previous year and a half, and it sealed the fate of the project. There was no going back.

Next, I started to increase the pricing; 250€ became 495€, then 695€ and 795€, and finally 895€. To my surprise, it did not mean getting fewer customers. I guess any sub-$1k amount for businesses is peanuts, so the only thing these price increases changed was improving the revenue.

The current MRR for EmailEngine is 6100€ and grows steadily, which in Estonia, where I live, allows me to pay myself a decent salary so that I can work on my project full-time. The only regret I have is that I did not start selling my software earlier and only published free, open-source software. Yes, I have some sponsors in GitHub, but it has never been a substantial amount, ranging from 750 per month, depending on how many sponsors I happen to have. Selling to business customers is definitely more reliable and predictable than depending on the goodwill of random people.

Hypervel 框架

https://www.facebook.com/groups/498481680220886?multi_permalinks=9342481069154192

今天和大家介紹 Hypervel 框架，起初是爲了在公司導入協程到高 I/O 情境的專案中，又希望能幫助同仁能以本來熟悉的 Laravel 框架快速熟悉開發而生，去年還在公司專案中進行內測，這幾個月漸漸將先前未完成的功能與文件都差不多補齊了，於是決定來和大家正式分享~

Hypervel 是一個以 Hyperf 框架底層元件爲基礎（類似於 Laravel 和 Symfony 的關係），並將 Laravel 的底層元件全部重構後移植整合進來，解決原本 Laravel 元件在根本設計上沒有考量協程上下文切換會導致的 States Bleeding 問題，並使其能融入 Laravel Hyperf 框架中。基本上現在 Laravel 文件中能看到說明的基礎元件都已經全數完成遷移。

應該會有人好奇有了 Laravel Octane 爲何還需要 Hypervel 這種看似重複造輪子的新框架？根本原因在於由於 Laravel 在核心設計中是完全沒有考量協程切換問題的，所以即便是 Octane 也只能透過將框架常駐記憶體執行來降低每次 request 的請求成本。但是 Laravel Octane 並未支持任何 Non-Blocking I/O 的特性，若是你的系統沒有 I/O 密集的情境其實 Octane 還是有幫助的，但對於 I/O 需求較重且響應較慢的請求 Octane 會變得一點作用也沒有。

舉個例子，近幾年隨著 AI 蓬勃發展，越來越多產品在自己的服務中整合 LLM 來提供服務，而每次的 LLM 請求可能都是好幾秒鐘起跳，你會發現你的服務在請求量多時 worker 數量就會瞬間耗盡，而你能做的只有拿出魔法小卡來進行 vertical 或是 horizontal 的 scaling。

如果你本身是 Laravel 開發者，在你使用 Hypervel 時你應該會覺得很容易上手（當然開發者要對常見作業系統、I/O 與協程等概念有一定程度掌握才不容易踩坑），以下爲 Laravel Hyperf 主要的特色：

  • 提供與 Laravel 框架相同的優雅開發體驗，減少新框架的學習成本
  • 極高的性能，QPS 在非 I/O 情境下比 Octane 高 10 倍，I/O 密集情境下高出數百倍
  • 內建的 I/O 相關元件，甚至是 PHP 內建的 I/O 函數都能自動協程化
  • 物件池與連接池的支援
  • 能無縫與你既有的 Laravel 專案透過 Cache、Lock 與 Queue 進行雙向溝通
  • 對於協程支援不僅限於處理使用者的 HTTP 請求，連 Queue 與 Scheduling 都能透過協程達到一個 Process 抵上原本 Laravel 需要開數百個 worker 才能達到的併發能力

歡迎有興趣的大家嘗試，詳細內容可以參照官方網站：https://hypervel.org （文件也是從 Laravel 搬運後修改的，因此會像在查 Laravel 文件一樣親切😂）

爲了避免混淆以爲他是 Laravel 框架以及註冊商標考量，框架重新命名爲 Hypervel

好多沒用過的 Server 端 Node.js 功能

Backlinks