從 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 專案應該是可以考慮的方法,有地方可以問的確會方便不少。

Travis CI 停止提供服務給 Open Source 專案

Hacker News Daily 上看到這個,在講 Travis CI 終止對 open source 專案的服務:「Travis CI is no longer providing CI minutes for open source projects」。

有不少專案已經改用其他 CI 服務的 free tier 做,像是 GitHub ActionsCircleCI 都有提供。

看了一下 Hacker News 上的討論,不少人是可以理解不會有永遠免費的午餐,只是這次 Travis CI 的處理讓大家覺得比較討厭的是,一方面官方一直跟 open source community 說我們很願意支援 open source community (前幾個禮拜官方 blog 還有發文重申這件事情),另外一方面是一直在朝著關閉服務走:從限制 10K credits 開始,到現在不會再提供 credit 給 open source 專案。

有人整理了對應的時間軸:

? 2018: Travis CI announces they are starting the process of merging travis-ci.org, which provided free builds for OSS projects, into travis-ci.com, which until then was only for paying customers. They promise OSS builds will continue to be free.

? 2020: Travis CI announces they are shutting down travis-ci.org at the end of the year and all projects have to move to travis-ci.com. They promise OSS builds will continue to be free.

Early November 2020: travis-ci.com switches from providing unlimited builds for OSS to only providing 10k one-time credits by default. Projects that meet certain guidelines (e.g. no one paid to work on them) can apply for recurring credits.

Later in November 2020: CI for many OSS projects that had migrated to travis-ci.com starts to fail, as they've exhausted their 10K credits.

Dec 2020: If what is reported here is accurate, Travis CI stop providing any recurring OSS credits. CI breaks for the remaining OSS projects on travis-ci.com.

Jan 2021: travis-ci.org shuts down. CI will be broken for all projects using it. They'll have the option of migrating to travis-ci.com, but will soon break again as they exhaust their 10k credits.

這種服務非常吃 CPU resource,大型專案如果每個 push 或是每個 pull request 都跑一輪完整的測試,成本應該不低,大概可以理解為什麼 Travis CI 會這樣決定,不過態度就...

其他家有提供 free tier 的 CI 最近應該會湧入不少人,這幾個月可以看看其他家會不會也跟進,另外一方面應該也會有人開始自架?

打穿蘋果的企業網路

上個禮拜丟出來很轟動的一篇「side project」,三個月不斷的打穿蘋果的企業網路:「We Hacked Apple for 3 Months: Here’s What We Found」,對應的 Hacker News 討論可以在「We Hacked Apple for 3 Months (samcurry.net)」這邊看到。

在最後面有提到這本來是打好玩的,但後來就投入愈來愈多時間進去:

This was originally meant to be a side project that we'd work on every once in a while, but with all of the extra free time with the pandemic we each ended up putting a few hundred hours into it.

這是五個人通力合作打了三個月出來的成果,依照他們的回報數字,共打出了 55 個「洞」,考慮到週休的情況,幾乎是天天打洞出來玩:

There were a total of 55 vulnerabilities discovered with 11 critical severity, 29 high severity, 13 medium severity, and 2 low severity reports. These severities were assessed by us for summarization purposes and are dependent on a mix of CVSS and our understanding of the business related impact.

文章裡沒有對每個安裝漏洞都描述,但有針對一些比較「有趣」的漏洞說明,雖然看了以後知道是怎麼一回事,但對這些手法沒這麼熟,你叫我打我還是不會打啊 XDDD 反而是當作表演藝術來看...

Scrum 的適合場景:「外包團隊」

在「工程師幹話」的『老闆想要成長 — 我們就讓老闆「看見」成長』這篇裡面提到了 Scrum

台灣最接近 Scrum 的組織是國軍。一個 Scrum team 不應該太大,所以一個班只有九個人,然後有一個直接的 PO,叫做班長;每天工作之前都有的 standup meeting 呢,叫做早點名;至於固定時間都有的 retrospective 會議呢,叫做榮團會。所以,如果我們真心相信有個 Scrum 外型的組織就可以提昇效率的話,就等於,我們居然會願意相信:中華民國國軍是個高效率的組織。

這篇文章花了半個小時才看完,真是有夠長的... 裡面描述了很多事情,與一些時間線對一下,大概知道哪個段落在講什麼事情。

之前跟其他朋友聊到 Scrum 的時候我都有先說我的結論,就是我覺得 Scrum 只適合用在「外包團隊」與「業主」之間的互動,目前看到的其他情境都不合理。

利用 Scrum 的架構,可以改善傳統的外包情境:

  • 通常業主給不出完整的 spec,於是外包團隊無法估算成本,所以外包團隊利用 Scrum 機制,每個 sprint 可以要求業主每次提供一點 spec,然後依照這些 spec 估時 (點數) 並且計費 (換算成 manhour,然後得出人力成本與利潤)。
  • 如果業主一開始就可以給出完整的 spec 也沒關係,spec 先切出第一個 sprint,在每個 sprint 結束後,跟業主確認下一輪的內容。

Scrum 在外包團隊可以掌握的範圍,大幅改善了傳統外包簽約的困難。

對於業主不知道要做什麼的,可以降低業主一開始就需要提供很多資料 (spec) 的門檻。

而對於業主已經知道要做什麼的,可以提供修改的時間點。這對於超長期的合作時特別有用,像是軍事外包案常常一個外包就是五年或是更長,sprint 的機制讓業主可以在中間很自然的修改規格,而不是加簽附約的方式修改 spec。

另外,在簽署 Agile Manifesto 的 17 人名單也可以看出來,裡面專搞 Scrum 的差不多都是在外包或是在當顧問,那麼,推出一個「學派」再告訴客戶這樣做會更好,是個自然不過的事情了。

而從 Scrum 裡面的其他細節也可以看出來他們怎麼把外包團隊想要避開的問題「包裝」起來賣給客戶:

  • 透過大幅縮短 milestone 的設計「sprint」,可以依照每個 sprint 收款,也因為通常 sprint 的單位長度比 milestone 的時間短很多,外包團隊的現金流的品質會比以前好。
  • 在 daily standup meeting 可以取得目前專案的進度,一方面可以在內部追蹤,避免有項目出事,另外一方面可以向業主回報,讓業主有安全感。
  • 再來是 Scrum 要求每個 sprint 的內容不可以被變更的問題,這點則是避免了客戶端的手伸進來,而改變了成本結構導致虧本。但也提供客戶修改的空間:允許下個 sprint 修改,重點在於該收的錢有收到。

而以上的這些東西放到公司內就會變得很奇怪:

  • 外包公司不在意手上做的產品是不是合理,只在意工時 (人力成本) 合不合理。而公司內的團隊合理性的才會下去執行,甚至有可能做到一半才發現不合理而需要全面中斷 (因為 startup 常常在做一些以前的人沒做過的事情)。
  • 在外包公司裡,PO 無法伸手進 sprint 修改既定事項,要硬改就是得照合約先把這個 sprint 的錢付掉,所以這情不太會發生。而在公司內 PO 常常是老闆或是大主管,伸手進來改不會有什麼賠償成本,Scrum 的這條規定在公司裡面就是沒有罰則的法律。
  • 公司成員遇到問題卡住 (不知道怎麼解、自己不會解、需要別人一起幫忙解) 或是進度會跟不上的情況應該是發現時馬上通知,而不是擺爛等到隔天的 standup meeting 才提出來。於是你會發現找不到 daily standup meeting 的目的。

另外一個問題是:

  • 營運端的成本造成估時不準確。像是上線後,系統的 downtime、bugfix 而使得原來團隊成員需要支援的情況,導致一個人的輸出不可能有 40 hours/week。

這點也是在外包公司不會遇到,而公司內不可避免會遇到的情況。

差不多把該講的都列出來了,這是我覺得外包時用 Scrum 適合的原因。

擋廣告的 Pi-hole

Pi-hole 最近愈來愈紅的一個計畫,技術上是透過 DNS 把不想要的網域名稱擋掉,通常就是擋掉各種 tracking 與廣告系統。

因為是透過 DNS 擋,當然沒有像 uBlock Origin 直接 parse 網頁內容來的有效,但對於方便性來說則是大勝,只需要在網路設備上設一次,所有的裝置都可以用到。

剛剛看到「How a Single Raspberry Pi made my Home Network Faster」這篇,可以看到 Pi-hole 有不錯的介面可以看 (讓你自我感覺良好?XD):

文章作者跑了一個月後,也直言還是有些東西會壞掉,需要設定一些白名單讓他動:

Review after 1 month in operation
The Pi-Hole has been running for 1 month now on my home network. I have had to whitelist 1 or 2 URLs which was blocking a reset of an Alexa which had an issue, and a video conferencing system had all sorts of tracking and metrics built in which were causing some havoc until I whitelisted them. Otherwise, the Pi has been chugging along at 8% memory utilization, and the network is considerably faster when surfing the web.

對於手癢自己玩應該還可以,拿到辦公室的話應該會有不少東西掛掉... (不過文章作者好像想這樣做)

非 Google 的 Android 手機環境

主要是記錄下來,完全不靠 Google 目前還是有點難度:「De-Googling my phone」。

主要是刷機成 LineageOS (還是 Android),然後上面不裝 OpenGApps,而是靠其他軟體來補足... 在英文版維基百科的「List of free and open-source Android applications」也有不少資訊可以看。

另外一個蠻重要的應該是 microG Project,不過在文章裡沒提到...